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

[Adam Williams <adam morrison-ind com>]

> > > > > -- 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.
> > > > none of those were in the above 2-point list.
> > > That thing that I am trying to explain is that if you actually
> > > attempt to implement the functionality in the 2-point list, 
> > > and try to use it in a distributed, multi-user application,
> > > you would discover, sooner or later, that you need additional
> > > functionality, above and beyond what libgda does today.  However,
> > > after implementing all of these whiz-bang, multi-user, distributed
> > > features, you would still have a 2-point sytem: something that
> > > copies data between objects and other sources.  We do not yet have 
> > > this 2-point sytem.
> > the multi user aspects are usually very well covered by powerful RDBMS,
> Yes, that is why we support only postgres, and not mysql.

There is a relatively "dumb" solution,  why not read the data for the
current view from the database with "select for update..." so the
records are locked?  Isn't that what such features are for?  I mean
"real" corporate systems 'get away' with doing it that way?  But it
isn't good enough for a system like GnuCash?  On the other side of my
partition wall is a corporate accounting department - and multiple
people don't edit the same exact view of data at the same time - or at
least hardly ever and if they do they get a "Record Set In Use" message;
simple, elegant, and **IT**WORKS**.  If someone loads a view and then
goes on vacation the record locks expire (in the database) and the
database doesn't let you go back and crunch altered values - every real
database (even MySQL) works this way, and supports "select for update"
(even MySQL).  Why not just support passing a LOCK_ME flag when a select
is executed?

> > there's no need to implement all of that on the client side of things,
> > but just to get the client integrate in that multi user environment.
> That's not true, there's still a whole lot of stuff that needs to 
> be done on the client side.  Neither postgres nor oracle will 
> magically reach into my app and manipulate my objects; I have to 
> do this on the client side, with my own code.  Its a highly 
> non-trivial excercise.

Not even non-trivial, but horribly brutal, borderline impossible, IMHO. 
By not using locking I can't see how some very-low maximum user limit
isn't going to be hit without moving to a client/server architecture
with some type of data-broker. 

> > for future libgda releases, like doing a CORBA provider, or a SOAP
> > provider that allows access to data sources in remote machines.

Please!  That would be fabulous, and better than JDBC-via-RMI (although
that works suprisingly well).  Mono supports object remoting over
CORBA;  I know that GDA was once upon a time CORBA/ORBit related, but
that was removed.  Is it possible to remote a GDA object? (I think
probably not).

> Yes, well, that would be nice.  We've played with that too.  GnuCash
> has an RPC backend that is no longer maintained, and at one point
> had an an html backend (a pre-SOAP xml-rpc-like backend).  
> They both more-or-less worked at one point in time.

Since GNUCash is a GNOME app has bonobofication ever been considered?

> Just having RPC (or soap or corba) doesn't make an app instantly 
> multi-user.  If a user updates an object on one machine, and another 
> user touches the same object on another machine, there have to be 
> all sorts of rpc (or soap) messages exchanged between these machines 
> and the server.  

Or with CORBA they could just share the same object, all depends on how
it is designed.