DConf configuration system

[Joerg Barfurth]

Hi,

[Not xposted to dbus-list]

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?
> After all the reading, I think these should be the features of the system:

I don't think this covers everything that has been discussed. And I am 
not sure everything you list already has been agreed to.

> - Notification of changes

ACK

> - Support for system defaults and some more selectable defaults for
> different types of users, which stack one on top of other

ACK. Besides supporting defaults it should also support making these 
values mandatory.

> - Undo/redo feature

It has been mentioned that a transaction concept could be used to build 
undo/redo on top of it. I don't think the system itself needs to support 
this. Maybe it just isn't clear enough what 'undo support' means at this 
level. I can certainly think of some API design details that help 
clients to support undo, but I wouldn't call that a built-in undo/redo 
feature.

> - Several backends

ACK. But we need to clarify the purpose of this.

> - Transaction concept, which ensures integrity at all moments

Basically yes. But again we need to drill down what we really mean with 
this. What properties do we want to guarantee?

> - Something else?

Some sort of access control is surely necessary and need to interact 
with the capability to make values mandatory.

Also there are some implied requirements about what constitutes a 
configuration system, which need to be spelled out. Both key namespaces 
and value data types make for interesting discussions. Another issue is 
availability of various metadata.

Lastly, in order to help transition there should be a way to implement 
client APIs of existing configuration systems (gconf, kconfig, 
OpenOffice.org, mozilla, [more?]) on top of this system.

One more requirement that has been mentioned occasionally is support for 
schemas, which can take on various levels of sophistication and strictness.

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

The daemon should also merge the data from the stacked data layers, 
implementing the precedence semantics on the way.

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

Sounds OK. This approach probably implies that the configuration system 
inhertis rules for names from DBUS, doesn't it? It appears I need to 
have a closer look at DBUS namespaces.

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

Here I disagree. That would only be useful for providing a unified 
interface for managing data that is stored in different configuration 
systems that continue to be necessary and useful. A 'gconf backend' in 
this sense would relay requests to gconf as it is now - with another 
daemon and everything. Logically these systems would be disjoint.

But the goal of D-Conf was to provide a new API to which all desktop 
applications could transition, and for which all desktops would have 
bindings. That means all bindings share the same storage and semantics. 
This also allows administering configuration for all clients of this 
system using only one set of tools, but in a very different (and 
superior) way. It also allows defining new shared keys.

This means that the existing backend pieces (e.g. gconfd) won't be 
needed any more, so you needn't be able to mount them.

In my view stacking should take precedence. Some of the stacked backends 
could implement this sort of partitioning, but I don't think 
partitioning makes sense for all layers of the stack nor that all layers 
need to support the same partitions. For example the user preferences 
layer could partition data into non-sharable, sharable arch-dependent 
and sharable arch-independent data. OTOH there could be a read-only 
layer that maps data read from system configuration or queried from 
system services into our configuration system and namespace as either 
defaults or mandatory settings. A layer that has group or department 
defaults might not need any partitioning.

> - IMHO, every backend should implement the support for default values,
> as the storage will be different for different backends, but there
> must be some common interface to modify these defaults. This needs
> more work.

To me it is the other way around. The various layers of the stack should 
come from various backends. Typically they are stored in different 
locations.

Some get their (default/mandatory) data from a central, shared location 
or a source that outside the realm of D-Conf. Such backends would be 
read-only to D-Conf. This means that some defaults can't be changed 
through the common interface. OTOH with your architecture it could be 
difficult to even address the correct layer of the stack in which a 
default modification should take place, as the composition of the stack 
may be different in various parts of the namespace, so you have to know 
the way to address layers for each 'mounted' partition. With my proposal 
you address the backend which should apply the modification and the 
backend is responsible to apply it to the named key.

> - Ideas?
> 
> I am already developing some similar system which is working quite
> well, but I need to see a bit more what are the real needs of the
> different desktops.
> 

I think we are still not very far in the collecting and sorting of the 
requirements.

BTW: Is there any need for the 'mount' feature, except unified access to 
existing configuration (backend) systems?

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