D-Conf

[Joerg Barfurth]

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.

>>On Daemons:
>>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 
application state.

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

Ciao, Joerg