Re: Using XML to handle all configuration files

[andrew@pimlott.ne.mediaone.net (Andrew Pimlott)]

On Fri, Jan 19, 2001 at 12:02:59AM -0300, Nicolás Lichtmaier wrote:
>  The problem I see is with shared data. e.g.: Supose there are several web
> browsers and each one have their own configuration files. Supose that they
> doesn't understand http_proxy and that you want them to share that variable.
>  Should they share all their data in a common configuration data model for
> browsers? Or some other mapping could be built on top of their own
> configurations, like a config file saying:
> 
> Package 1:
> 	XPATH:				debconf style space:
> /browser/network/proxy			browsers/http_proxy
> 
> Package 2:
> 	XPATH:				debconf style space:
> /browser/some-xml-node/proxy		browsers/http_proxy

I think you are talking about maintaining an XML file and building
the real ("run-time") config file from that.  This is nice and
simple, and doesn't screw too much with an administrator's
expectation that there will be a "normal" config file to edit.
Presumably, you will include a strategy to avoid overriding manual
changes and comments by the administrator (eg, put a checksum in the
file when you write it, and bail out if it later doesn't match; or
do a similar thing with finer granularity, ie, checksum sections of
the config file or even individual options, and only overwriting
those sections; or verifying by careful inspection that
sections/options written by your tool haven't been changed by the
administrator, then rewriting them in place).

I want to suggest that you keep another possibility in mind.  That
is to have the native config file include data from your XML format,
instead of having the XML-based tool write the native file directly.
That is, instead of something like

    # This option automatically generated.  Touch at your peril!
    foo=bar

write something like

    foo=`configurator-get-value foo`

This requires either that the run-time config file support this, or
that you generate the run-time config file from a template (in
native format + eg m4).  In the second case, the admin must be
instructed to edit the template and type eg "make" to rebuild the
run-time file, but that is not much of a restriction in exchange for
a graceful (and actually working!) combination of hand- and
configurator-editability.

Andrew

-- 
Capitalism interprets regulation as damage, and routes around it.