D-Conf

[Sean Middleditch]

On Fri, 2005-03-04 at 19:36 +0100, Lars Hallberg wrote:
> Philip Van Hoof wrote:
> 
> >On Fri, 2005-03-04 at 10:40 -0500, Sean Middleditch wrote:
> >
> >
> >  
> >
> >>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.
> >>    
> >>
> >
> >This is exactly what I initially tried to say about all this. I don't
> >think a configuration subsystem really needs to be designed to handle
> >system configuration nor early-boot-up anything configuration.
> >
> >It just needs to handle the configuration of desktop applications and
> >perhaps some desktop-related major applications. Perhaps in time the
> >configuration of, for example, X.Org. But surely not the configuration
> >of your MTA nor of your Apache webserver or init.d scripts. Basically,
> >none of the files which are at this moment located in your /etc/.
> >  
> >
> I don't agree, lets take a real life example.
> 
> I just instaled a ubuntu system for a freind.
> 
> It set everything up sanely for a newbee. But my frends isp don't allow 
> outgoing smtp conektions, to fight spam or virusmail or somthing :-/ So 
> I had to change the postfix conf to use the isp smtp server as 
> smarthost. Easy for my, but on a 'typical' desktop install, a non sysop 
> and newbee is alone at fixing this. It *needs* be part of the config 
> system. It need to be easy to find and alter.

That doesn't need it to use the Desktop Configuration system.

> 
> That means this config *must* be accesable and alterable from the config 
> system, and the config system must handle aktivation of the changes 
> (/etc/init.d/postfix reload). Idealy it also provide a nice and easy 
> undersandable gui :-)

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.

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)
 - Network transparency
   (I doubt you want that for system services, it would make them too
   unreliable)
 - Change notification
   (fairly unimportant, since you can just SIGHUP most system services
   after editing their config files)
 - Ability to share settings between applications and let those apps
   change the settings
   (useless for system services)
 - Existing API to reduce development time
   (this is the only one that makes sense for a system service)

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.  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 i dos not mean that postfix must use the config system. I personaly 
> prefer that system softvare keep using files in /etc, and that those 
> files is actorative (if I alter the file with emacs, the changes is 
> visable in the config system).
> 
> But the config system should anderstand them, be able to showe them in a 
> consistent tree, be able to change them and activate the changes.

That's a LOT of extra code in the configuration system where bugs can
hide and resources can be wasted, and most of the important reasons for
having the D-Conf system will be wasted on those files.

There are configuration systems around that tried this and, for the most
part, they've all failed.

> 
> The way to do that is to allow specifik plugins for specifik subtrees of 
> the config. Thes plugins shuld be instaled and hoked up to the tree by 
> the distribution. Shuld not add anny complexity to the user.

It won't give the user any benefit either, since having access to
cryptic files using a cryptic "registry editor" isn't really an
improvement at all.  You're changing the interface to the configuration,
but you wouldn't actually be simplifying it at all.

If you feel that Postfix, Apache, or so on all need better configuration
tools, I'd certainly agree.  There *are* GUI tools for configuring MTAs,
web servers, and so on.  The reason for their lack of popularity tensd
to have very little to do with the underlying configuration and mostly
to do with those tools have very poor user interfaces.  Switching to
D-Conf can't and won't fix bad user interface design.

> 
> /LaH
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>