Re: dbus and GNOME 2.8

[jamie <jamiemcc blueyonder co uk>]

On Wed, 2004-04-07 at 10:39, Rodrigo Moya wrote:
> On Tue, 2004-04-06 at 20:22 +0100, jamie wrote:
> > 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)
> > 
> we all know that, since we all know SQLite is just a simple embedded
> database. The question here is not what RDBMS is the best, but what uses
> there are for a full-featured RDBMS in a normal GNOME desktop.



Uses/advantages for an RDBMS in Gnome :

1) client/server architecture - gives you complete network transparency
for free. EG An admin user can remotely configure GConf, view
appointments of other users on the network or make use of any other
facility remotely if its on an RDBMS for free - no extra development is
required for this as the same client apps would function on the local
machine DB or a remote one. (you also get security here for free too) 

2) Robust and reliable. All data validation can be easily done on the
server. RDBMS make light work of this (things like referential
integrity, cascading updates/deletes, check constraints, triggers etc
all help keep your data safer and are quickly/easily implemented here).

3) Use of stored procedures eliminates the need for extensive wrapping
of stuff in C, which would take longer to do and probably mean no RAD
for the GUIs/front end apps (you can still of of course create a light
wrapper for easy use in C without affecting this). If we cant make use
of the Gnome-DB widgets for front end GUIs then it would be a huge
disappointment and we are back to doing things the hard/slow way. If its
no quicker or easier to use a DB than it is to use custom
implementations based on IPC mechanisms then there's no point
having/using it in the first place. Anyone who's used the data aware
widgets in Delphi or VB knows how much development time is saved by
using them and it's substantial.

4) Triggers and events give you two way interaction via notification
signals which seem to be needed by Gnome Storage and useful for other
apps too.


jamie.

> 
> It makes more sense to me to add RDBMS-storage support to some parts of
> GNOME, like a GConf backend, for instance, and let people choose to use
> a RDBMS if they want to.
> 
> > > 
> > > > 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! 
> > 
> we need middleware to allow concurrent access to flat files. That is
> what e-d-s does.
> 
> cheers
> 
>