Re: dbus and GNOME 2.8

[jamie <jamiemcc blueyonder co uk>]

On Tue, 2004-04-06 at 19:46, Sean Middleditch wrote:
> 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.  ;-)

I have what you said was crap - see the feature list for sqlite and now
check out firebirds :

http://www.firebirdsql.org/ff/foundation/FBFactsheet.html

SQlite is a zillion miles away from being an RDBMS... (gotta be the most
primitive DB I have seen as it sacrifices functionality for speed
bigtime)

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

Dunno about mysql but its certainly faster than Postgres.
> 
> > > > 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?

Yes it is. On firebird I can define check constraints and business rules
far quicker and easier than in C. The language it uses is declarative in
nature so a lot quicker than procedural C for that kinda thing.

Large corporations use middleware for three tier client server systems.
Why because it scales better than two tier systems when you get over the
100 simultanoues user count. For a desktop - We dont need a monster
RDBMS nor monster middleware cause we only talking about user counts of
1 or 2. Creating middleware means more work, more bloat and slower
performance.

> 
> > 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.
No it is not - its in the middle! We dont need middleware for 1 or 2
users on a DB! 

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

Business rules always change - fact of life.

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

I was referring to accidental screw ups rather than deliberate ones.

> 
> > >   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 has user defined functions which are used from an external lib

>   It
> provides callbacks into user code?
Yes it has events that can can be called in triggers and stored
procedures.

>   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? via UDFs yes

>  It has a complete
> debugger?
yes it syntax checks it for you for stored procs - which is all you
need. UDF's can be debugged in isolation using GDB.

> 
> 
> > > 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.
> 
Maybe a different backend might work - theres no guarantee of that.

> 
> > 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?
RDBMS was not on the dependancies list for Gnome core more like. With
Storage its likely to be now.
> 
> 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.
not for DB access you dont - its not needed at all - it just slows the
system down.

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

stored procs can do all that - you could create a generic API that gives
access to all the stored procs and get exactly the same effect without
knowledge of the tables or any SQL. If you want consistency then go that
way - we still get all the benefits then.

> 
> Honestly, what actual problems does the RDBMS solve?  Not which problems
> *can* it solve; what problems does GNOME actually have that it solves? 

RAD + saves extra coding effort with IPC mechanisms. The problem with
Gnome is that a lot of it is developed the hard way and sure mono would
change that but also an RDBMS cause of the extras you get for free. I
dont want to rehash every time so please read all my previous emails on
the subject for further details.


> What advantages are there to rewriting the entire platform as a set of
> stored procedures in an RDBMS? 

Who said anything about rewriting?

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

Okay for an addressbook, I could plonk a dbgrid widget down from
Gnome_DB and set a few properties, create a DB connection and in no time
display the contents of that table on my form. If I use an API, I have
to call it, create probably a treeview widget, a liststore and manually
retrieve all the data and hook it all up. Takes a lot more effort for
one simple case - now multiply that extra time and effort by the
thousands when designing bigger apps and it all adds up.  We dont have
RAD components for APIs - more work you are proposing? Jam tomorrow but
not today?

jamie.

> 
> > 
> > jamie.
> > 
> > 
> >