lah at micropp.se
Sun Mar 6 14:34:54 EET 2005
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
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.
More information about the xdg