Requirements and pre-analysis for a cross desktop configuration infrastructure

[Joerg Barfurth]

Hi,

cobaco (aka Bart Cornelis) wrote:
> On Thursday 10 March 2005 21:15, Philip Van Hoof wrote:

>>The backend  needs to support default settings which are stored on a for
>>the users  read-only  location. For  example: the  user  settings go  in
>>$HOME/.dconf/ and the defaults go in /etc/dconf/default/.
> 

> it needs more then that: 
> - it needs what kde calls 'cascading configuration', i.e. multiple 
> configuration sets that can be stacked, and activated conditionally (say 
> one set of configuration for admins, one for management, and one for 
> ordinary office workers, stacked on top of common base-settings)
> 

Yes.

> -> the basedir spec provides for the stacking
> 

I don't think that is sufficient. Different layers in the stack can come 
from different sources and for some of them a capablity for live updates 
of settings is desirable. File system directories are not the right kind 
of storage for this and a accordingly a list of directories is 
insufficient for stacking. See below for examples.

> merging of the different configuration sets should with be done with a 
> granularity of individual settings (not config files). And ideally there 
> should be a mechanism to mark settings as can't be changed by user (similar 
> to kde kiosk system)
> 

A stacked system would probably also be used to get delegated and 
distributed administration. Thus this feature should be extended to mark 
setting as can't be overridden by lower-precedence configuration sets. 
Ultimately this implies that the setting can't be overridden by user 
preferences - so the user effectively can't change it.

> NOTE: gconf supports the above though somewhat hackisly:

The OpenOffice.org (OOo) configuration also has similar features with 
different implementation approaches.

> - for the conditional activation of what gnome calls 'configuration sources' 
> you need to generate a path file on login AFAIK, which I find rather ugly

OOo requires an ordered list of backends as initial configuration. 
Currently we don't have a path file for this but a single variable, 
which is a little clumsy to handle. OTOH we allow a single backend to 
provide multiple stacking layers. Such a backend can determine the 
number and order of layers dynamically.

Currently we handle multiple directories for file-based data as 
individual single-layer backends. But there could certainly be a 
multi-layered backend that e.g. evaluates XDG_CONFIG_DIRS.

A more dynamic backend provides plugin capabilities to inject settings 
from 'foreign' data sources into the configuration tree. Here it is 
sufficient to register a plugin with our component system (UNO) and it 
will automatically be queried for data. Thus the backend that handles 
this can produce as many layers as there are plugins.

There exists another backend using the dynamic capabilities of this 
system, which collects configuration sets from an ldap directory based 
on role and group membership starting from a user id or host identifier. 
Unfortunately that system is not free atm :-( But this is the kind of 
thing we will need for large-scale administration purposes.

> - any locking of settings needs to be done by splitting out the locked 
> settings into a separate 'configuration source', which needs to be 
> carefully ordered in the path file to be looked at before the user 
> settings, which makes it a pain to switch things from mandatory to 'may be 
> changed'
> 

The OOo system has defaults and mandatory settings together in one 
layer. The file format incarnation of this uses XML and it really needs 
it: XML attributes are used to specify protection of settings as 
mandatory, to control the merging process (e.g. there is an attribute to 
discard an entire subtree of the hierarchy and restart it from scratch) 
and more (localized values, NULL values).

Switching a setting (or an entire subtree) between default and mandatory 
is as simple as changing an attribute value between "false" and "true".

Ciao, Joerg