configuration system notes

[Joerg Barfurth]

Hi,

Havoc Pennington wrote:
> I just posted this also:
> http://www.gnome.org/projects/gconf/plans-spec.html
> which is an example rough spec for a system that addresses the points in
> http://www.gnome.org/projects/gconf/plans.html
> 

Lots of good stuff. And there are several things where you came to the 
same conclusions as I did for OOo configuration [*].

> I don't know if it's possible to get Mozilla and OO.org on board or not;
> there are several tricky aspects, including cross-platform and that at
> least oo.org has such a huge amount of data in the system (I can't
> imagine all of that data is what we'd consider "preferences" on the
> GNOME/KDE level, but I don't know). 

It isn't. The OOo system was primarily designed for preferences. But 
then the system was there and developers in the project came to 
appreciate its capabilities and use it for different things. In the end 
you can design for some uses. But you can't prevent uses above and 
beyond your intentions, if the system works well.

Some of it is application state. Defaults for application state are very 
similar to preference defaults. This ranges from saving windows states 
across sessions to crash recovery information.

Some is configuration data, like lists of installed and enabled filters 
or lists of supported label types. By using the config system this 
configuration can be easily extended or restricted by users and 
administrators using the same mechanisms as for preferences.

And in OOo 2.0 some people started to use the support for 
locale-dependent values to store larger numbers of UI strings :-o

OTOH custom menu and toolbar configurations, custom color palettes, 
hatch patterns and similar stuff are currently not stored in the 
configuration system. That data is very close to being preferences.

I don't think that everything that people store in gconf is purely 
preferences either. But I agree that the added use cases of current OOo 
can't be design drivers for a desktop config system.

> I think it would be OK to skip these
> apps at first if it looks intractable to cover their use cases. But it 
> would be nice to cover them if possible.
> 

The cross-platform aspect is probably the most problematic for moz and 
OOo. OTOH both have componentized preference systems which provide some 
integration points. (Alas, in mozilla some old netscape stuff is still 
not replaced everywhere...) And the suggested changes certainly go in 
the right direction to provide closer integration.

> Existing systems are not right:
> 
>  - Uniconf solves a different problem (gluing together other systems)
>    while punting on important aspects of what we should be doing here.
>    "Make it configurable" is not a good answer to most programming 
>    questions (not even the question "how should the config system work")
> 

>  - Elektra has its priorities wrong. The obsession with avoiding a 
>    daemon and supporting early boot breaks more important goals.
>    If you need a no-daemon mode, make it a special case, not the normal 
>    case.

>  - ACAP is a standard nobody uses, and is pretty different from 
>    the ideal design, so I see no reason it's interesting.
> 

Nice summary to which I subscribe.

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