D-Conf

[Lars Hallberg]

Sean Middleditch wrote:

>>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.
>  
>
Having all config avalible thru the same API is a huge win. For writing 
network tramsparent config tools, for writing software to automaticly 
analyse the sanety in a network site, security of on machine etc.

Geting the system app to read the config thru this API is no real point. 
The /etc/files is a rock solid solution. But maken the config readable 
and alterable thru one comon API is a huge win for system tools.

>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.
>  
>
No, gui will not apera magicly. But if the conection between /etc/files 
and the api is ther, writing gui is a magnitude simpler, having a good 
and consistent api. And if D-CONF catch on and have a esay way to add 
such glue, that glue might start to be provided by the system app 
developers themself.

But however, it need not be part of D-CONF core, if D-CONF will be not 
totaly broken, it's api shuld be usable by a standalone deamon that synk 
realtime betwen /etc/files and D-CONF. If D-CONF don't suport 
activation, just add a config key foo.barr/app/activation-status, seting 
that to 'activate' could tell the deamon to activate new changes.

Then sysadm can chose to run that deamon or not, if they don't the 
/etc/files works as always. If the demon is not started jet in the 
bootprocess, or if the deamon crach - the etc files is still there.

/LaH