Re: [gnome-db] Re: GRAND MASTER PLAN

[linas linas org (Linas Vepstas)]

Oi vey,

On Tue, Mar 09, 2004 at 08:39:13AM -0600, Linas Vepstas was heard to remark:
> On Mon, Mar 08, 2004 at 05:29:43PM +0100, Rodrigo Moya was heard to remark:
> > > > 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). 
> > > 
> > > This sould VERY much like .Net's ADO.  At least to me.
> > > 
> > that's also basically what libgda does. Not the socket stuff, but the
> > other things are already available via libgda and libgnomedb.
> 
> Rodrigo,
> 
> I can't beleive you just said that. Let the flame wars resume.

My apologies.  I am loosing my temper instead of explaining more
clearly what it is I'm talking about.  It is wrong of me to flame.
What I really need is a better koan.

> What DWI/QOF/gnucash currently does, and what gnomedb DOES NOT DO
> is:
> 
> -- an object query system. libgda does not.
> -- a uuid system. libgda does not.
> -- an object persistance infrastructure. libgda does not.
> -- a multi-user object caching and cache-coherence system. libgda does not.
> -- a data-set partitioning system. libgda does not.
> 
> This is maybe the fourth or fifth time you've said that "gnomedb
> does this" and maybe the fourth or fifth time I've said that 
> "gnome db has the wrong abstractions in place to correctly 
> support these necessary features!"

A simple example, in C++ this time.

Let us say we have a C++ object:

class MeinBlau {
	public:
		char * get_blaupunkt (void);
		void set_blaupunkt (char *);
	private:
		double blaupunkt;
};

Let us say we have a "Grand Master DB Interface".  I want to 
prostrate myself before the Grand Master and say:

"Oh grand master, in your infinite wisdom, there is an SQL database
somewhere, and it has a table with a record with UUID=123.  Please
copy that SQL database record into my object MeinBlau."

I want to do the above with one subroutine call:
grand_master_copy_from_sql (MeinBlau *myobj, char *Use_the_sql_driver);

There is an assumption that at some earlier time, I made declarative
statements that explained which sql table fields get hooked up
to get_/set_blaupunkt.

I want to go on:

"Oh grand master, in your infinite wisdom, I know that there is
another SQL user out there who is editing and modfying this database.
Please always make sure that my object is kept in sync with that
database.  Please provide me with an event or a callback or means
of polling such changes made by others."

"Oh, and by the way, when I change *my* instance of this object,
please notify these distant, remote, other users on the other 
side of the planet that my copy now contains the most recent 
data, and please put that data back into the sql db for me."

------------
Now, because the grand master has the buddha-nature,  it can satisfy
these requests if I substitute the words "gtk widget" for "sql database"
in the above prostrations.  Or the words "abiword document". The
word "sql" simply helps identify the data source.

-----------
Now in fact, I have many instances of class MeinBlau, and I need to
perform a set of operations on it.  I want to be able to say:

"Oh grand master, I have many pointers to many instances of MienBlau 
in my bag, but I am blind and cannot find the ones I need.  Can you
help me find those with blau>2.5 ? Oh, and grandmaster, I know that
not all such instances are in my bag.  Some are very far away, in 
a remote database.  So can you please search over those too, and 
hand me pointers to those as well? (oh yeah, and keep them in sync 
too)"

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