DConf configuration system
ppatters at nit.ca
Wed Apr 6 19:01:02 EEST 2005
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
> > - 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:
> 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.)
Net Integration Technologies R&D
More information about the xdg