DConf configuration system

[Buola Buola]

On Apr 6, 2005 5:18 PM, Sean Middleditch <elanthis at awesomeplay.com> wrote:
> 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.
>
Yep... that's why I'm ready to start working on it if we can agree on
some things

> > 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.
>
I don't think that it's a problem that backends have to recognize the
/ character specially... we could even use some escaping mechanism if
it is necessary.
I think it actually simplifies things because then we can provide a
DBus object for every folder (I think it is too much to do it on a key
basis) and be able to receive notifications per folder. It's then also
possible to do commands like "retrieve all keys in that folder" and
such things
It also makes it much easier to namespace configuration keys

> 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.
Same applies the other way round. Backends can unbreak folders into
full keynames if it helps them.

>
> > - 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 idea was to be able to have different backends mounted at
different points, to make transition easier, and to be able to access
other configuration systems using this interface. Actually in the
system I have started developing I can access the whole gconf tree at
/gconf and some kde keys at /kde.
It will also help mixing the modification of settings for
non-DConf-aware applications creating a backend for their
configuration files and using the same interface.

> 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.
>
We will be able to do it because only one process will actually do the
changes accessing the different plugins, so it will be atomic for
applications which use this API
> > - 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>
>
>

Xavi