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

[linas linas org (Linas Vepstas)]

On Wed, Mar 10, 2004 at 05:09:29PM +0100, Rodrigo Moya was heard to remark:
> On Wed, 2004-03-10 at 10:03 -0600, Linas Vepstas wrote:
> > > 
> > > > -- 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'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.

It gets even harder when multiple tables need to be updated 
simultaneously, atomically.

> And if you need multi user environments for data sources that dont
> implement, there are very "easy" solutions, some of which are planned

"planned" is the key word here.  gnucash has supported the sql backend
since 1998, here we are five years later, and things are still planned. 

I was hoping that this would be a good time to discuss how things should
work in these future planned releases,  because we've gone through a
number of iterations on this side, and have a fair idea of what works
and what doesn't.

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

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.

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.  

I want the object programmer to feel like they are working with this
simple "2-point" system, while under the covers there are all these
soap/corba/rpc messages flying around keeping things coherent and 
in sync.  Handling the locking and etc.  

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