Re: Using XML to handle all configuration files
> 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).
The idea isn't to have two files. The XML version will probably never be
written to the disk. It actss just an intermediate common data model.
And the XML file sould capture everything, including comments. Yes, the
disadvantage would be that the system will reorganize comments a bit when
the file is regenerated.. =)
> 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.
The idea is to avoid making any changes in how programs work.
Reply to: