DConf configuration system

[Sean Middleditch]

On Wed, 2005-04-06 at 16:53 +0200, Buola Buola wrote:
> I have been reading almost every post about the someday-will-be
> desktop configuration system and it seems that almost everything has
> been talked about and some things agreed and some not.
> Has someone started working in actually doing something about it?
> A lot of other freedesktop projects have already been working for some
> time and they have had some acceptance, so... why not start the DConf
> project and expect it to be accepted?

Somebody has to do the actual work.  ;-)  Just saying, "Hey somebody, do
this now!" isn't going to help anyone.

> After all the reading, I think these should be the features of the system:
> - Notification of changes
> - Support for system defaults and some more selectable defaults for
> different types of users, which stack one on top of other
> - Undo/redo feature
> - Several backends
> - Transaction concept, which ensures integrity at all moments
> - Something else?
> 
> Proposed way to implement it
> - Central daemon which has the backends as plug-ins. Clients can
> connect to it using a DBus API (there will have to be bindings for
> different languages and desktops, as there is for DBus, but it hasn't
> been a problem so far). The daemon will provide the change
> notification, the undo/redo thing and the transaction support.
> - The configuration data has a filesystem-like look, with folders
> which contain keys and values (maybe supporting values of the DBus
> types). Every folder will be a DBus object, implementing some
> interface to access the values and keys.

Why should it have folders and all that?  It really shouldn't be
anything more than a key/value database.  The keys might look something
like UNIX paths, but that doesn't mean they are - the engine doesn't
need to specially recognize the / character or anything.  Making it
actually folder-based doesn't buy you anything, but it could potentially
complicate backend code.

Instead of setting properties like access privileges and such per folder
or per key, you could do it using patterns.  For example, a rule in the
system configuration could state something like:
  # admin can edit panel config, users cannot
  /app/gnome/panel/*: root(rw),*(ro)
That then would just be something compared with any keys using fnmatch
(or something similar).

That would also work for notifications.  The app can just say that it
wants to be notified for the keys:
/app/gnome/theme
/app/gnome/panel/launchers/*
/app/gnome/nautilus/*

Those slashes don't actually need to mean anything to the configuration
daemon (although backends might do something with them for
organizational purposes during storage).  Just a simple string match.
For performance reasons you could state that the only formats available
or either a plain string (whole string match) or string with a wildcard
at the end (prefix match).

Backends could go ahead and break things into folders if it helps them,
but they shouldn't be forced to.  A pretty efficient and fully function
SQLite backend could be implemented with very little code using plain
string keys.

> - The different backends will be "mounted" somewhere into this
> filesystem, so for example you could have a GConf backend mounted at /
> and then some other systems mounted on it.

Why?  Just for kicks?  Sounds like over-engineering something just
because you can or because it sounds cool.  You don't even need to make
backends as plugins.  If you're using D-BUS, you get swappable backends
for free - just setup a different daemon binary as the service manager
for the DConf address, and so long as the binary implements the DConf
interface, it'll work.  No need for making a big over-complicated
plugin-managing filesystem-shadowing singing-and-dancing configuration
daemon at all.

The multiple backends will also give you all sorts of hell just as bad
as you get with UNIX file systems today.  For example, you can't do an
atomic creation of a directory tree if that tree needs to span multiple
mount points in UNIX.  You'll end up with the same problems in a
configuration daemon using multiple backends at once.

> - IMHO, every backend should implement the support for default values,
> as the storage will be different for different backends, but there
> must be some common interface to modify these defaults. This needs
> more work.
> - Ideas?
> 
> I am already developing some similar system which is working quite
> well, but I need to see a bit more what are the real needs of the
> different desktops.
> 
> Thanks for your time,
> 
>      Xavi
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>