Re: Using XML to handle all configuration files
On Sat, Jan 20, 2001 at 12:27:44PM -0300, Nicolás Lichtmaier wrote:
> 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.. =)
This is not unreasonable, but I think there are some serious
drawbacks to your approach.
1. It doesn't allow you to implement a new config file format
piecemeal, because you have to be able to round trip the entire
format to your XML and back. This means that you have to write a
full parser (covering all the quirks the format may have--to wit,
I'm sure some config files are really Perl code), capture all the
semantics (again, watch for those quirks!), test it thoroughly to be
sure it doesn't mangle complicated config files, and commit to
keeping in sync with changes to the format--all this before you can
deploy it at all. It would be much easier if the system allowed you
to handly only a few options at first. If the system has too steep
a curve, nobody will write handlers for new config files.
2. Including enough information (about comments, order of options,
etc) in your data model to make a round-tripped config file come out
reasonably well (ie, minimal changes at the character level), you
will have to uglify and complicate your data model. This is not
only unesthetic, but it makes manipulating the model harder (almost
as hard, perhaps, as the original format). I don't think this is
worth it. Better to have a clean data model that is easy to work
with.
3. Even reorganizing the comments is obnoxious.
I think you should strive to keep the data model you expose (to the
configuration tool or whatever) simple and clean, and expect that it
will not be isomorphic to the config file. Instead, think about how
you can gracefully map your model onto the config file, using the
suggestions I made (eg, having the config tool own only part of the
config file, or having the config file include data from the XML
model).
In short, there's a place for text-based config files, and a place
for abstract data structures, and you should try to let each do what
it does well.
> > 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.
Read again--I start from the same premise. Either the config file
already supports inclusion of remote data (eg, environment
variables, program output, include files), or you tell the admin to
edit a "template" version of the config file and type "make" when he
is done. The second case changes how the config-file-addicted admin
works, but neither changes how the program works.
Andrew
--
Capitalism interprets regulation as damage, and routes around it.
Reply to: