D-Conf

[Joerg Barfurth]

Sean Middleditch wrote:

> Unfortunately, D-Conf will not make easy and understandable GUIs
> magically appear for all D-Conf using applications.  All it would do is
> create something similar to regedit or gconf-editor, which hard
> experience has proven are exactly the opposite of easy and
> understandable GUIs.  They are administrator tools that exist ONLY
> because there is no other easy way to access the configuration stores.
> The nice and easy configuration GUIs must still be designed and built
> specifically for the target application.
> 

But if there is a unified API for configuration data access and 
manipulation that makes creating such a GUI easier. If I want to create 
an administration frontend, I don't really want to create parsers and 
generators for all the different configuration file formats and 
activation mechanisms.

> You don't need D-Conf to do that.  The thing that D-Conf actually brings
> to the table and that are actually useful are:
> 

>  - Administrator control of user preferences
>    (useless for system services, since there is no difference between
>    default/user/mandatory settings)

Even for system services you may have a similar distinction: domain, 
site or workgroup admins can provide default or mandotory settings for 
an entire site or a class of machines that serve a particular purpose or 
user group. Computer-specific configuration can be used to customize 
this for a single machine or to add the settings you can't share.

>  - Network transparency
>    (I doubt you want that for system services, it would make them too
>    unreliable)

Even a desktop should still work as reliably as possible when the 
network is down. OTOH there may well be system services for which you do 
want some form of network transparency. You can't completely dismiss 
network dependencies even for system services, otherwise there wouldn't 
be systems like NIS.

But to me the real network transparency requirements aren't all that 
clear yet: What should be transparent across what kind of network and in 
which way?

>  - Change notification
>    (fairly unimportant, since you can just SIGHUP most system services
>    after editing their config files)

Yes. Event/IPC-based change notification is primarily a desktop feature.

But even for system services it is useful to have an API to activate a 
set of changes, instead of hardcoding the specific mechanisms to do this 
for the various supported services in a configuration editor.

>  - Ability to share settings between applications and let those apps
>    change the settings
>    (useless for system services)

I agree that system services usually don't change any settings 
themselves (éxcept to store application state across sessions, for which 
purpose configuration systems are often abused ). OTOH sharing settings 
may actually be useful even for system services.

>  - Existing API to reduce development time
>    (this is the only one that makes sense for a system service)
> 

In the end very much boils down to this. A unified data format for 
frontends and archival also may make sense. Still it needn't necessarily 
be the same API and data format for system and desktop configuration, 
much less the same storage and implementation.

> Of those, the only one that's really helpful is the last, but it's not
> particularly *that* helpful.  Really, all the D-Conf API would bring is
> a barely simpler replacement for open/read/write and some basic parsing
> code.  

My experience is that that does make a difference.

> Most system services I'm used to have a lot of configuration that
> isn't just simple setting of keys, but things like writing out filters
> or setting a series of key/value pairs that have to make sense in
> context to each other.  Again, D-Conf (nor any other configuration
> system) can't magically do that for you - you either need to know what
> to type in or have a GUI specifically built for the target application
> to assist the user.
> 

But if you have a frontend framework and a unified api for the actual 
parsing, generating and activation, then building a useful GUI for 
another system becomes much easier and may in many cases be done in a 
declarative fashion without requiring a C programmer.

Ciao, Joerg