GRAND MASTER PLAN

[Dru]

Linas Vepstas wrote:

>On Mon, Mar 08, 2004 at 01:43:44AM +1300, Dru was heard to remark:
>  
>
>>Overall vision:
>>
>>A complete database toolkit set that allow the easy rapid application 
>>development of custom db appliations for gnome. Also a collection of 
>>common business applications like accounting, payroll, inventory etc.
>>    
>>
>
>Yes. Although I already have a problem with terminology.  
>"database" is the wrong word, as it implies sql. Its broader
>than that.  I want two abilities:
>
>1) the ability to take data, be it from sql, an xml file, or 
>   something ephemeral that came over a socket, and convert
>   it into a set of C-language objects that can be manipulated
>   and searched and operated on.  (Note that a possible data
>   source is a gtkentry widget...)
>
>2) the ability to suck data out of the c-language objects, and
>   shove that data back to an sql database, or to an xml file
>   or to a socket, or into a gtk widget (for display) or into
>   an abiword document (for display). 
>  
>
Alright i understand. I dont think gnome-db or me has anything close to 
doing this.
And i think the only thing  i have seen close to it is the code you 
showed me.

>The reason I like C objects is that as a programmer, I can 
>do all the whiz-bang application-specific coding easily when
>I have plain-old c objects to work with.  As a lazy application
>programmer, its a real hassle to get the data into and out of
>xml, sql, etc. These data formats are "inaccessible".  So my 
>vision for the toolkit is something that converts these 
>"inaccessible" data sources/sinks into plain-old c objects 
>that I can easily work with.
>  
>
I know what you mean. i stopped trying to populate c style structures 
from db's, sockets etc a while ago.  I didn't like having to write new c 
structures for every table, and a couple supporting functions for 
mapping values in structure to values in db. 

>>Forms creation.
>>I think we all seem pretty confident in glade here. thats solved.
>>    
>>
>
>Uhh, forms and reports are two sides of the same coin.  Remember
>my 'bugzilla' analogy:  The bugzilla "report" for bug 123 is also
>a "form" that allows the user to modify bug 123.   I'd like to 
>be able to embed widgets into abiword docs, and use libglade-like 
>api's to find & work with those widgets.
>  
>
i see this more as custom widgets than reports.

>>Data abstraction layer.
>>
>>This layer that deals with dynamic data sets. Doing the write backs and 
>>saves of data.  There is libgda, bonddb, gnueappserver, qof. Dont touch 
>>gnueappserver, i wrote it and it suxs. I dont think we can look at 
>>working together on this one until we sort out the low level abstraction 
>>db.  How far are you down the track for qof linas?
>>    
>>
>
>Not that far.  I really need to prototype the conversion of my 
>'generic C objects' to/from SQL in order to confidently say 
>"this approach works".  I was going to do that last christmas...
>I have all the pieces ready and checked into cvs,  I have the 
>master plan in my head, but I have to assemble the damn thing. 
>
>If I had this prototype, then I would be mentally prepared to 
>talk about things like 'triggers' which I know that you use. 
>Mentally, I'm not there yet, not enabled for input.
>
I see the difficult bit is manging invidiual tables, and when you have a 
source of a select statement or view, do you create another c structure 
to use it.  Its amazing how a programme langauge that hasnt changed in 
decades evolves so much over the years.

>>Reporting
>>
>>reporting engine, what is gnomedbs requirements? Linas, maybe a gtk 
>>output engine or a xml to gladexml converter, or use the existing html 
>>    
>>
>
>Reporting is on the same coin as forms, its just on the other side.
>A "form" flows data from somewhere else to my application. 
>A "report" flows data from my application to somewhere else.
>
>This is THE "high level" abstraction layer/API, to me. 
>
>My app codes to this high-level API.  It then picks a particular
>driver.  There is one driver that will push data into an abiword
>doc.  There is another driver that will push data into a pane
>of gtk widgets. There is a third driver that will push data 
>into xml.  There is a fourth driver that will pushd data into
>sql. A fifth driver will push data into ldap.  A sixth driver
>builds a web page and pushes it out to Apache. Etc. 
>
>(My "DWI" project was my attempt to create this high-level API.
>I currently have drivers for glade/gtk and sql.)
>
>Its possible that gnomedb and/or libmergeant has this kind of 
>ability, but if so, I haven't figured it out yet.  Its not
>clear how to create new drivers.
>
Kindaof in a lose sense. no c structures, no apache support.  you'd have 
to write a wrapper code
from GdaDataModel to c strctures that worked majically. You'd also have 
to write wrappers around gnomedb widgets so you can paint/read a 
collection of widgets at the same time. You'd need have another 
structure that you attache to the widgets and DataModel (or use hash lookups
by some unique charatisitic) that stores your publishing and state 
information.
Its a different approach to gnome-db, and libmergeant is proberly not as 
mature/well developed yet as you'd hoped.  It saves you a lot of time 
for individual drivers but its not an easy path to make it stick.

>>Report Designer.
>>
>>None of have anything here (expect gnue).  Its needed. I was thinking 
>>orginally using openoffice or abiword to design reports but i really 
>>havn't started looking at this at any detail. Any suggestions on how we 
>>are going to achive this? Does this sound feasible?
>>    
>>
>
>I've been trying to explain to Martin Sevior what my vision for abi
>is, and I think he almost gets it. I thnk once he gets it, it will be
>easy.  I want abi to have a libglade-like interface.  The report
>designer creates a named text block, and my program can then change
>the text/color/font of the named text block.  I can't beleive this
>is going to be hard.
>
Tell him to go use gnucash.  I was thinking a 2 phase process here with 
lots of xml conversion. (like how bond does it now), but that costs 
resources a lot if its done on the fly.

>--- 
>Note that the above should be called the "abiword report designer".
>The "gtk report designer" is still glade.  The "xml report designer"
>is presumably some hand-written DTD's or xml schemas or something.
>Some types of reports don't need report designers.  
>
>The point again: the "report" is really just a pushing out of data
>from my app to some other place.
>
>  
>
>>Finincial Objects.
>>    
>>
>
>Excellent point.  I have my heart set on "workflow objects", which 
>deal with users and seeing which users can make modifications to 
>which objects at what point in time.  e.g. only a person of type 
>"manager" can approve of "chair purchase".  This might sound
>wildly off-topic, but its not:  The point is that these "transactions" 
>should be easy to build on top of the data abstraction layer.
>
>If it is hard to build these types of objects on the data abstraction
>layer, then we will have failed with the data abstraction layer.
>  
>
Do you do double entry book  keeping when you store the records?  Maybe 
if we both use double entry book entry then have naming conventions or 
mapping of accounts.