Re: ORBit-like /tmp functions

On Thu, 2004-07-29 at 00:25, Curtis Hovey wrote:
> On Thu, 2004-07-29 at 01:02 +0200, Chipzz wrote:
> > On Wed, 28 Jul 2004, Jamie McCracken wrote:
> > 
> > > We can nuke gconfd when we get round to incorporating an embedded
> > > relational DB in Gnome (would seem a waste not to if medusa/storage is
> > 
> > What about apps not using the gnome libs, but only gtk+ and gconf?
> The plan for Medusa is have a dbus/soap interface to insert and retrieve
> metadata.  Any app may use those protocols to set/get data.  For many
> subjects/objects, the metadata itself may be treated as first-class
> data--recent files, bookmarks, window state.  GConf key data could be
> accommodated, but I don't Medusa will be a good choice per its current
> plan.  GConf has data typing and validation and I'm not sure Medusa's
> handling will be adequate.

Any decent relational DB will support all that for free AFAIK only
Sqlite is short in that department. What DB does Medusa use if any?

> I have not worked on Medusa in 6 months.  I suck.  Plans are subject to
> change, so Medusa isn't out of the question.

Would you like a hand?

I would ideally want the desktop to be centred around a DB so instead of
the messy proliferation of dot files everywhere we would have a nice
centralised fast store. A db would offer far more as well cause it could
be used to cache VFS directory contents (IE by storing last modified
date of a directory in the DB we could pull the data for a directory
straight from the DB too if the date hasn't changed) this would speed up
Nautilus considerably and go slow things like SMB would also rocket. VFS
caching and file indexing go hand in hand so they should share the same
> Storage is a better long term solution, but it only exposes a gnome-vfs
> for access.  I like to think of Medusa as a Storage subset, so I would
> want to port the dbus/soap access Storage when Medusa gives up the
> ghost.  Storage should get dbus regardless because Storage needs to
> handle events for users and applications.

Storage in my opinion is only useful for documents and in particular
documents containing text because substring matches could be then done
more efficiently in SQL (instead of grepping). Medusa is much better for
system wide use and binary stuff - I dont see the point of having mp3
files in storage as thats silly and wasteful so we need both medusa and


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]