Re: dbus and GNOME 2.8

[Sean Middleditch <elanthis awesomeplay com>]

On Tue, 2004-04-06 at 14:08, jamie wrote:
> On Tue, 2004-04-06 at 18:30, Sean Middleditch wrote:

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

http://www.hwaci.com/sw/sqlite/
Read the Wiki notes, and/or the source.  ;-)


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

I don't know of any benchmarks against firebird in particular.  It
definitely beats the other two popular Open Source database' pants off
tho.  Is Firebird *that* much faster than PostgreSQL and MySQL?

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

What do you think gconf, eds, bonobo, gnome-vfs, etc. all are?  They are
layers of software that sit between the application and the "dumb" data
store, which is what "middleware" is.  def: "Software that connects two
otherwise separate applications OR separate products that serve as the
glue between two applications."

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

More effort?  What are you smoking?

> 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

The middleware *is* the server, and *it* offers network transparency,
probably using an already written and tested library like ORBit, bonobo,
D-BUS, etc.

> are, the API is not (different machines could have different versions of
> the API with different rules).

No, the API doesn't change when developed properly.  That's the whole
point of using an API - the database schemas *do* change everytime you
want to make a little modification somewhere, while the API can stay
stable for *years* with only API additions.  An API is a clearly defined
stable contract.

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

And that happens even with a DB.  I can go in a rm -fr
~/.gnome-rdbms/table2.  I can open up the files and just changes the
schemas or add/remove stored procedures.  If people want to fuck things
up, they're going to fuck things up.

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

This language can pull data off the web?  It can query across several
distributed databases stored both on the local network and online?  It
provides callbacks into user code?  It can signal events over D-BUS?  It
can link to and utilize useful libraries installed on the system in
whichever language the developer wants/needs?  It has a complete
debugger?


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

No, you wouldn't.  You'd use a different backend.  Why?  Because the API
encapsulates and hides *all* of those nitty gritty details.  Which you
can't do when you start having apps dip their fingers right into the
datastore.


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

The evolution developers had that option from the beginning.  Perhaps
you should ask them why they chose the model they did?

Even so, any individual app can choose to use an RDBMS.  Nothing stops
them.

> 

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

We already have it.

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

No, because you just missed the entire point.  We don't *want* people to
do things twenty different ways, *especially* when one of them is
"directly access the stuff that the apps shouldn't bloody care about." 
It's "encapsulation."  That doesn't just mean we have an API to make
things easy.  It means everything is forced through a stable API to
ensure everything actually works.  It hides implementation details.  It
provides consistency.  Forward compatibility.  etc.  Where possible,
we're trying to move away from the very model you're proposing.  We are
adding more APIs to encapsulate stuff that wasn't previously done well
enough.  We're cutting out redundant methods towards a unified clear
whole.

Honestly, what actual problems does the RDBMS solve?  Not which problems
*can* it solve; what problems does GNOME actually have that it solves? 
What advantages are there to rewriting the entire platform as a set of
stored procedures in an RDBMS?  Show some concrete examples of how it
gets easier.  Show us how accessing a database directly is simpler and
more powerful than a clean well-designed API.  Explain how RAD with a DB
is so much better than RAD with API hookups?  (which is pretty cool, I
might note - I'm not aware of an existing tool that does this for C/C++,
tho - it's definitely possible and not too difficult to implement, tho)

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