DConf configuration system

[Joerg Barfurth]

Hi,

Patrick Patterson wrote:
> 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. 
> 

Is there any place where I can see what is actually there (except the 
source). I looked at the UniConf site repeatedly, but it appears to be 
rather stale. In any case it appears to be much more targeted at 
providing unified access to system or legacy configuration data than at 
the kind of desktop configuration system that has been discussed here.

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

OK.

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

I haven't found a clear description how multiple superimposed Gen things 
interact; I have found nothing how this interacts with write access and 
access control.

>>>- Undo/redo feature
> 
> UniTransactionGen
> 

Unod has at least two parts: One is 'transacted' multi-key operations. 
Another is capturing the keys modified in a transaction and their prior 
state. Do you put this all in your TransactionGen?

>>>- Several backends

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

I am not conviced access to preexisting 'foreign' or 'native' 
configuration systems is the primary use for pluggably backends in a 
desktop configuration system. One reason is thst is hard to define a 
meaningful and useful set of guaranteed semantics that any such backend 
can provide. Usually one has to resort to a least common denominator 
with limited utility (and this is the first impression I got on your 
UniConfSemantics page).

>>>- Transaction concept, which ensures integrity at all moments
> 
> See above UniTransactionGen
> 

It really depends on what your understanding of 'transaction' and 
'integrity' is. I can't see how you can build anything that deserves the 
name transaction on top of the semantics you require from the actual 
storage backends.

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

Do you have a documentation of your DBus API? I haven't even found one 
for your C(++) interface.

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

Your 'mount' concept and namespacing rules do attach special 
significance to slashes. The client interface (which is probably 
different from the backend interface) should offer that abstraction. And 
without folder support iteration of direct children can be very expensive.

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

I don't think you can attach access priviledges to keys or folders in 
the namespace directly. In a stacked scenario they apply to instances of 
a key in the various layers (e.g. I may be allowed to change my personal 
preference, but not the group or site default). IME it is even 
sufficient to apply access priviledges to entire layers. Any such access 
control also has to correspond with other ways to modify the underlying 
data. This fits the access control by layer model well. Protecting a key 
is not much use, if the user can change it by manually editing a config 
file. OTOH you don't want to store user preferences in a file that only 
root can modify.

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

I still don't know what this is good for, if your goal is not to wrap 
existing legacy systems.

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

Doesn't sound like it has actually been use for desktop configuration. 
And how scalable is it? Are there any big applications or system that 
use the UniConf API to access their configuration?

FYI: OpenOffice.org 2.0 configuration has ~75 components (top-level 
keys) with ~3000 key entries in the associated schemas, queries up to 8 
backends by default (for all of these components) and has ~31000 values 
for ~22000 keys in its default data. Quite a lot of this is loaded 
sometime during startup, so the performance of this is critical for 
application startup time. Of course for a desktop system the amount of 
data in the backends will be a multiple of this and a daemon has to deal 
with concurrent requests from multiple applications.

Ciao, Joerg

-- 
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         joerg.barfurth at sun.com
OpenOffice.org Configuration          http://util.openoffice.org