Requirements and pre-analysis for a cross desktop configuration infrastructure
jub at sun.com
Mon Mar 21 18:40:34 EET 2005
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)
> -> 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
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".
More information about the xdg