DConf configuration system

[Patrick Patterson]

On Wednesday 06 April 2005 11:18, Sean Middleditch 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.
>
Well, we've (Net Integrations and the WvStreams Hackers) have already done a 
fair bit of work in this direction - along with the Elektra folk. 

> > After all the reading, I think these should be the features of the
> > system: - Notification of changes
Yup - UniConf does this.

> > - Support for system defaults and some more selectable defaults for
> > different types of users, which stack one on top of other
Yup - we've got a UniDefaultGen, and a UniPermGen.

> > - Undo/redo feature

UniTransactionGen

> > - Several backends

We can store things in DConf, INI files, the file system, the Elektra system, 
and it's trivial to write more.

> > - Transaction concept, which ensures integrity at all moments

See above UniTransactionGen

> > - 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.
UniConf Daemon already does this.


> > - 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.
>
UniConf talks via DBus :)

> 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.
>
Yup - that's what we decided - 

> 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).
>

Yup - that's what we found...

> 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.
>

Yes - UniMountGen does exactly what you want...

Check it out - http://open.nit.ca/ and click on UniConf - it's here, it's 
today, it's already deployed to thousands of servers, it's scalable, it has a 
testing framework... and when you only use Elektra, it's even lightweight :)

(The only drawback is that it is C++ and depends on WvStreams, but we're a 
workin on it - we've got C# and a couple of other bindings in the works.)

Patrick Patterson
Net Integration Technologies R&D
http://open.nit.ca