Re: dbus and GNOME 2.8

[jamie <jamiemcc blueyonder co uk>]

On Tue, 2004-04-06 at 18:30, Sean Middleditch wrote:
> On Tue, 2004-04-06 at 12:59, jamie wrote:
> > On Tue, 2004-04-06 at 16:46, Alan Cox wrote:
> > > On Maw, 2004-04-06 at 00:31, Jan Morén wrote:
> > > > Let Markus run Postgres, let Jamie run Firebird, let me run MySQL, and
> > > > perhaps have SQlite as the default, built-in provider in case no DB is
> > > > actually installed by the user?
> > > 
> > > Agreed. SQlite's great strength is the zero-setup side of things, a big
> > > database strength is the centralisation, LDAP's is mirroring and so on.
> > > Its not useful to try and define a "one true solution" here
> > 
> > Well SQLite is not an RDBMS - yes its a database but nothing more. If
> 
> Perhaps you should read up on SQLite some more.  It supports everything
> most "real" RDBMS, including all the features you mention below.
Really do you know a url to confirm this?

I have read it up and its not an RDBMS. More of a primitive DB like
paradox and xbase.


>   And it
> does it all much much faster with much less resource overhead than any
> "big" RDBMS I know of, embedded or not.

Faster? Using variants for types I doubt that very much. It might
outperform Postgres but I would be very surprised if it beat firebird.



> 
> > all we want is dumb data storage then yes SQLite is all we need but the
> > biggest advantage of having an RDBMS with stored procedures and triggers
> > is that we can centralise business rules for the data in order to
> > protect its integrity and avoid additonal coding effort by duplication
> > of said business rules in multiple clients (the clients become thin
> > clients which are quicker to code and less buggy as a result).
> 
> Be it in the world of big business and databases or little ol' GNOME,
> that problem is generally taken care of by "middle ware."  For example,
> Storage is middle-ware - it sits between the application and the
> underlying data-store and provides "business" rules and facilities.

Since when did we need middleware on the desktop? AFAIK, Corba is only
being used as a component model in Gnome
> 


> Generally, middle-ware can be a lot more powerful, flexible, and easy to
> use than database stored procedures.  App authors don't want to start
> writing SQL (and the tons of security implications that come about when
> you need to start writing dynamic SQL statements, be it in C or any
> other language) - they want to call gnome_addressbook_get() or
> whatever.  The library and/or daemon that sits between the app and the
> datastore (be in filesystem, an XML file, an RDBMS, or wireless
> encoder/decoder to the users' brain) handle all the gory details.  And
> handle it cleaner and simpler than the RDBMS solution could, because its
> A] portable among backends, B] clearly defined behind a documented
> static API, C] comprised of simple API calls.

Its also more effort and only suitable for indirect access to data then.
What about all the Gnome-DB widgets which would give us RAD - kiss bye
to them if we have to use only an API. For flexibility and to cater for
those who want to use an API and those that want to use Gnome-DB, the
business rules have to be on the server - theres no other way. You are
also forgetting about network transparancy - the rules on the server
are, the API is not (different machines could have different versions of
the API with different rules).

Having the rules on the server is the only safe way cause theres nothing
stopping a developer going straight to the DB or some clever dick who
plays around with a DB tool from screwing up your data.

 
> 
> Using an RDBMS, we'd first have to pick one.  And not just one, but a
> specific version of one, because a lot of RDBMS require the procedures
> to be re-loaded or even re-written between versions.
Interbase/Firebird has always been backwards compatible by supporting
multiple sql dialects in newer versions.

>   We'd also have to
> have another language flame-fest to pick the stored procedure language,
> since many RDBMS have provisions for multiple languages. 
Firebird doesn't - it has its own highly functional language.

>  Then,
> application authors would need to write these procedures, provide
> installation, upgrade, and deinstallation mechanisms.

Run an SQL script - not difficult.

>   Application
> authors would need to learn SQL, put up with constant headaches from due
> to SQL escaping, etc.  

Not needed - we have views and stored procs to simplify things.

> System adminitrators would have to learn how to
> enable/disable remote access to per-user database daemons for
> multi-machine environments (like my work).  Embedded systems like GNOME
> on iPaq would probably be screwed since the RDBMS system will quite
> likely be too big and complex to fit there along with everything else,
> since it needs to handle stored procedures and other "high end" features
> most embedded databases disable out of necessity.
I dont think you would get storage on there anyhow.

> 
> And that all doesn't solve the problem that RDBMS dont' in any way
> sanely model the real world data needs.  Real world data is object
> oriented with complex relations RDBMS map everything into
> tables/rows.  Just expressing a simple addressbook in an RDBMS can be
> utter hell.  And then trying to wrap your head around transactions
> (which would be necessary), a new stored procedure language, trying to
> built huge complex SQL SELECT statements to search the database... it's
> just a pain.

If you use have predefined stored procs or make use of a query building
tool then its dead easy. If you prefer an API for it you can have that
too - its no problem with rules on the server. You are greatly
exaggerating it - an address book is dead simple to implement in an
RDBMS.

> 
> An OODBMS would be much more appropriate.  An addressbook would be an
> object with children objects of address entries, which could be
> comprised of complex types like lists and such.  Searching the database
> would be simplified because you only need to worry about what you're
> searching vs SQL/RDBMS where you have to try to find the most efficient
> way to map tons of tables that have little relation to your data but
> have to exist because the RDBMS is incapable of intelligently modeling
> your data.

Well if you know of an OORDBMS then please tell it sounds quite
promising. I agree an OO one would be of more benefit.

> 
> And you know what?  An OODBMS is what we largely already have.  GConf is
> a simple such system, with a standard API in front of it, "stored
> procedures" in the GConf daemon implementation, etc. 
> Evolution-data-server is another such system.  Yes, they're both
> specialized, and could probably have a lot of code reduction by using a
> common data store (like Storage).  But would something like transactions
> in a RDBMS help?  No, beacuse they're already stuck behind a daemon that
> does things no RDBMS does the way we need (like change notification).

We have events for change notification in RDBMS like postgres and
firebird.

An RDBMS would have enabled E-D-S to have been developed a lot lot
quicker. Given the popularity of Corba amongst C developers, maybe they
would prefer an RDBMS route? I am proposing to give them both as with
rules on the server we can have as many API's or access methods as you
like.

>  
> Do we need stored procedures?  No, because the daemons can already be
> implemented in any language the developer wants with full language
> features,

More work, more debugging...like reinventing the wheel?

>  and not some dinky embedded language that's likely incapable
> of doing specifically what they need efficiently and easily.  And, to be
> honest, app authors would *much* rather use a library that maps those to
> a simple single API than have to start directly connecting to a RDBMS
> and invoking SQL statements.  And heck, if Evolution Data Server became
> reimplemented entirely in FireBird with stored procedures and SQL, the
> app authors would care or even need to know, specifically because we
> *do* use library wrappers and don't ask authors to invoke magic straight
> into the heart of the datastore.  EDS could even reimplement itself
> again in Oracle and still the app authors wouldn't even notice.  That
> being why even if we *did* have a standard RDBMS, we'd still have
> middleware and would still be able to and want to ignore things like
> stored procedures and SQL entirely. 

Thats fine I'm for both API access and Gnome-DB access. Middleware we
dont need on a desktop - do we need J2EE on our desktop? I think not.

To sum up - Having the rules on our server means we can use whatever we
like to access the DB be it from the network, a client side API or via
Gnome-DB and its DB widgets. Surely that would please everybody?

jamie.