[gnome-db] Re: GRAND MASTER PLAN

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 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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]