DConf configuration system
jub at sun.com
Thu Apr 7 16:35:23 EEST 2005
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.
>>>- 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
>>>- Undo/redo feature
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
>>>- 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
>>>- 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.
Joerg Barfurth Sun Microsystems - Desktop - Hamburg
>>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer joerg.barfurth at sun.com
OpenOffice.org Configuration http://util.openoffice.org
More information about the xdg