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@xxxxxxxxx> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
