[gnome-db] What DWI does [was Re: GnuCash page on GO site]

[linas linas org (Linas Vepstas)]

On Mon, Mar 01, 2004 at 10:17:18AM +0100, Rodrigo Moya was heard to remark:
> > 
> > http://dwi.sourceforge.net is the object framework I'm planning
> > on using for the future gnucash core engine.
> > 
> what are the advantages of this over libgda?
> could you ellaborate more please?

Well, for starters, and this is no mean fact, I am more familiar 
with DWI than with libgda.  That alone makes it easier for me.
Let me provide some history.

Originally, I developed DWI as a 'rapid application development'
platform, so that I could quickly code up some complex data-driven
apps for a client (The system monitored some industrial controls,
and kept maintenance records for them).  Think of it this way:

Suppose you wanted to develop 'bugzilla' from scratch, but 
you wanted it to have a gtk/gnome (glade) interface, and you 
wanted a generic sql backend.  This is kind-of what I needed 
to do.  Instead of coding from scratch, I realized that there's 
a generic abstraction:

A window full of widgets is "kind of" like an SQL table with one
data record in it: that window has a unique name (which
is like an sql table name) and the widgets all have unique 
names (kind of like sql column names).  Those widgets have 
values that can be "read" or "written", just like the 
columns in an sql table can be "read" or "written".

All I needed to do was to write an abstraction layer that made
sql tables and windows with widgets look alike, and then 
just-plain copy between as needed.  So for example:

pump_maintenance (repairdate, action_taken, cost, notes) 

was both the abstract view of an SQL table that stored this
info, and the abstract view of a glade-designed GTK window
that displayed this info.  

libgda seems to do something like this, but it only does it
for sql-like data sources.  It does not do it for gtk widgets
or glib gobjects.

That was version 0.1 of dwi.  

For version 0.2, I realized that what I had really written was 
generic system of shims between different types of object systems.
I could define an 'object' in a very easy fashion, just by
listing a table name and some field names, and the system could
then read/write, get/set values for those objects.   

It also provided the set of utilities I needed: a way of filtering
data before using it (e.g. format conversion), and a set of 
abstract, generic triggers (if user pressed button, then copy
data from widget to sql, etc.).  Most importantly, it allowed 
me to work in a declarative rather than proceedural fashion.
As a finaly advantage, its very small and very light weight 
for what it does: its maybe 5KLoc of code.

Now, I could argue that some of these DWI features should be
incorporated into glib gobjects, except that gobjects are 
already way too complicated and hard to understand.  Similarly,
maybe some of this should be put into libgda: but ...

Suppose I approached the glib gobject folks, and told them that
they should merge gobjects with libgda.  Everyone would think
I'm crazy, and they would say no.  So why should I bother? 
After all, I've already got a small, simple, easy-to-use 
library that merges gobjects with sql, and it does it in 
the way that I want it done.  So that's where I currently stand.

Re: the gnucash engine: I was planning on using DWI to provide
the shim that would translate the gnucash objects (including
the business accounting objects) to the database, and back.
The idea of using dwi would be that it would then become very
easy to add new types of financial objects.

Its possible that maybe I could use libgda for this instead;
however, I'm concerned that gnucash uses a number of fancy
constructs, and so it would be impossible without hacking 
the guts of libgda.  Worse, these hacks might not be accepted
as patches by the libgda developers.  So what was originally
a few weeks of coding suddenly turns into 6 months of 
arguing on the mailing lists; its a high-risk path for 
something that should be small, simple and easy. 


--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas linas org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933