jub at sun.com
Mon Mar 7 12:48:38 EET 2005
Sean Middleditch wrote:
> On Fri, 2005-03-04 at 16:12 +0100, P. Kaluza wrote:
>>Avery Pennarun wrote:
>>>- it should *allow* a central configuration repository with
>>> default/current/override settings.
>>Yup, allowing for multi-level configuration from day one will certainly
>>help acceptance. (I envisioned Schema Defaults/Distributor/ Site
>>admin/Computer admin/User, with Distributor, Site admin and Computer
>>admin having the ability to "lock down" certain keys.)
I think this really is a must. And the layering must be configurable[*].
The default OpenOffice.org configuration system has (roughly) Schema
Defaults/Distribution/Admin+Addons/System Settings/User Addons/User
Prefs by default. But if needed that can be extended, particularly by
using the pluggable backend feature. E.g. I have seen installations
which in addition to the above used e.g. Corporate Admin/Site
Admin/Computer Admin/Workgroup Admin, and where all these administrative
layers came from a central repository using a different backend. BTW:
for this repository we also have and use a gconf backend.
The 'System Settings' part also involves a different backend: here data
that is not owned by the configuration system is injected transparently
(as a read-only layer). This even uses a second layer of pluggability
for the various data sources. Existing sources in the OpenOffice.org
case include the desktop environment's system (gconf/windows registry),
environment variables[**] and LDAP attributes (e.g. user information).
[*] IMHO this configuration has the status of system-scope
configuration, so it needen't be handled by the D-Conf system itself.
[**] This one has the interesting twist that in can't be handled by a
daemon and is not shared between processes.
>>I can understand why for the "System scope" you'd not necessarily want
>>to involve a daemon - boot-time complication and security questions come
>>to mind. However, when talking about a desktop system, you really really
> More to everyone in general on this topic, not specifically a reply to
> this post:
> Does this hypothetical configuration system REALLY need to be designed
> to handle early boot up or anything like that? Is that perhaps just a
> tad bit of over-engineering for a DESKTOP configuration system? Does
> early bootup even NEED a new configuration system? Do the early bootup
> guys WANT a new configuration system? The target of the new
> configuration system is desktop apps, so there's not a whole lot to gain
> by worrying but applications outside your target application set.
I think there is need for a system-scope configuration system, but it
has vastly different requirements.
The one area where unification is desirable is frontends. Having common
administrative tools, or at least a common shell for both parts is
something actual users demand. But there are some fundamental
differences, which you can't fully hide. If a desktop- and system-scope
configuration system agree on some common concepts and keep the
corresponding parts of their APIs (i.e where there is overlap) similar,
that would help the creation of unified frontends. In some cases (e.g.
support for central configuration) there may be potential for sharing
some parts of the infrastructure. But that does not mean that is has to
be one system (or even one architecture) from end to end.
Thus we really should design a desktop configuration system without
worrying much about system configuration. If parts of our solution can
be reused for system settings - maybe with some refactoring - then that
would be great. But that isn't a real goal or requirement for the
initial design of a desktop configuration system.
> Does the configuration system really need multiple backends, instead of
> just writing one good one and leaving it at that? Aside from a single
> fast, efficient, secure, safe local-storage mechanism and a single
> usable remote-storage mechanism, what other backends could you need?
Even locally there may be differences in the requirements for storing
data that is read-only after installation (schemas), data that is
changed rarely in controlled ways (administrator-controlled defaults and
mandatory settings) and frequently written [***] user preferences. The
requirements for remote storage vary even more. Remote storage of
modifiable user settings and read-only access to centrally stored
defaults or mandatory settings has very different trade-offs. Data could
be stored remotely in one of several competing directory systems or
using some entirely different protocol (webdav, ftp, sql db server, ...).
And even if you think stacking adds overhead, so you shouldn't require
it, supporting the possibility for those who need it is a plus.
Transparently using data from system settings (e.g. /etc) as defaults is
one example of this. Other cases may occur for integration in
heterogeneous environments (sharing policies between a Linux desktop and
a Windows system anyone?)
[***] Even if you attempt to make this a non-goal, many application will
use an existing configuration system to store not only preferences, but
> I don't care about the geek factor; just because you can make a new
> backend doesn't mean you should. If there isn't a very strong case for
> NEEDING to switch backends... If you do need to switch backends, is it
> worth coding them up as dlopen'd libraries, or is the fact that you can
> swap in a different D-BUS daemon that uses the D-Conf service a good
> enough mechanism for changing "backends?"
As mentioned above I think multiple backends are most useful, if you
combine them with multi-layering. I don't necessarily want to switch the
entire system to a different data source. But I do want to mix and merge
data from multiple sources. Switching the configuration daemon allows me
to switch the top-level backend driver. But to mix data from multiple
sources I need a backend driver that supports pluggable backends. The
default backends from a simple standalone system are surely among the
backends I want to plug into my mixed stack.
And IMHO you are jumping the gun here. As far as I understand the
primary driver for using a daemon is notification capability. With D-Bus
this can probably be implemented without needing a dedicated
configuration daemon, or else using a very lightweight one which just
cares about managing the notifications. I am not yet convinced that
reading all the data via RPC and a heavyweight configuration daemon that
does all the backend handling is necessarily the right solution. If we
don't do that, we certainly use the ability to switch backends by
More information about the xdg