Re: dbus and GNOME 2.8
- From: jamie <jamiemcc blueyonder co uk>
- To: Danilo Segan <danilo gnome org>
- Cc: Mark McLoughlin <mark skynet ie>, GNOME Desktop Hackers <desktop-devel-list gnome org>
- Subject: Re: dbus and GNOME 2.8
- Date: Mon, 05 Apr 2004 22:17:58 +0100
On Mon, 2004-04-05 at 20:32, Danilo Segan wrote:
> Hi Jamie,
> Today at 19:53, jamie wrote:
> > Okay but we still have the problem of saving non-Gconf data. Do we
> > really want to have a host of different storage methods and repositories
> > or do we want to standardise on one system that handles all our needs?
> I believe we have that, and we call that a "file system". Improving
> filesystems in differing ways is already in progress, I just don't see
> why it would a-priori have to be RDBMS based. RDBMS are inherently
> not friendly to hierarchical data, which filesystems are usually
> optimized for. (Perhaps Object-oriented DBMSes are, but I don't know
> much about them.)
> If we were developing for Plan9, we wouldn't need to say anything
> else at all, but since we're slowly diverging from "everything is a
> file" to "everything is a file, but with some extra metadata" (then
> again, if we had the ability to use things like GNU Hurd
> "translators", this could be solved with the simple filesystem
> interface like /path/to/file.xml/metadata, or similar), then we need
> only worry about how to store the metadata.
> There're many approaches to that problem, and not all of them use
> a RDBMS. Filesystems are currently most stable, have the best
> performance, and best scalability when it comes to "data storage".
> Most of network protocols which are not explicitely file and/or
> filesystem based (like FTP or NFS) do not work with files, but rather
> with "messages" (like HTTP or MIME, which provide a bunch of metadata
> along with data in each message), so there's no problem in
> transferring metadata along with data itself across networks
> (i.e. there you get your network transparency even for files and
> metadata -- no need to think of anything else).
> When we can optimaly present data in form of simplistic "relations"
> (i.e. tables in a database), then we need to look up at RDBMS. "Data
> storage" doesn't mean relations by default.
> Now, with our "data storage" problems resolved, lets move on :)
I think You missed the plot. No one's talking about replacing the
filesystem with an RDBMS or anything crazy like that. The RDBMS is
simply for storing and retrieving meta data.I was suggesting
standardising the use of that RDBMS for other related stuff.
Currently we are using a flat file XML database for GConf whilst some
services like Evolution Data server achieve the same effect of an RDBMS
by presenting its data via Corba. Package managers use their own file
based databases and now egg-recent wants to use corba or Dbus for simply
transfering data in a client/server fashion. Its clear from these
services that we need to have client/server support on the desktop and
an RDBMS is the best and quickest way to achieve that. Filesystems
cannot achieve any of that on their own (theres no substantial indexing,
cross indexing or querying facilities for all that meta data). So I have
to strongly disagree with your analysis - If you take a route away from
RDBMS you either end up with a mess of different databases and IPC
mechanisms for client/server operations or you code from scratch some
server similiar to an RDBMS.
> PS. Sorry if I'm a bit agressive, but as they say: "I know RDBMS, OOP,
> TCP/IP, LAN, MIME, FTP, HTTP and seventeen other technical/IT terms." :)
] [Thread Prev