DConf configuration system

[Buola Buola]

On Apr 6, 2005 6:01 PM, Patrick Patterson <ppatters at nit.ca> wrote:
> 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
> 

I will check this project. Anyway, I think that what we should do, is
creating a common DBus API, then it really doesn't matter how it is
implemented as long as the implementation works and conforms to the
API, and we need to make the Gnome and KDE who can decider whether to
adopt it happy with it. Once there is a DBus API spec which has all
the functionality, we can see if the existing projects can be easily
adapted to use it. It's not a problem if it is written in C++, as the
DBus API will be totally language-independent.