Re: dbus and GNOME 2.8

[Sean Middleditch <elanthis awesomeplay com>]

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.  And it
does it all much much faster with much less resource overhead than any
"big" RDBMS I know of, embedded or not.

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

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.

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.  We'd also have to
have another language flame-fest to pick the stored procedure language,
since many RDBMS have provisions for multiple languages.  Then,
application authors would need to write these procedures, provide
installation, upgrade, and deinstallation mechanisms.  Application
authors would need to learn SQL, put up with constant headaches from due
to SQL escaping, etc.  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.

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.

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.

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). 
Do we need stored procedures?  No, because the daemons can already be
implemented in any language the developer wants with full language
features, 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.

-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.