Re: Using XML to handle all configuration files
> > 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.
If we want any kind of automatic handling of configuration settings, we
need to modify these files. So we need some kind of trick to parse them,
modify and rewrite. The current solutions are often substandard, like
editing with sed, overwriting, generating a new config file each time the
user runs a configurator.
And when you have a configurator, you'd like to use the current values as
defaults, so you end up with many developers implementing their own way to
parse things.
Besides, I don't think there are such many cnfiguration formats. And the
most complex ones could be left out of this scheme until someone dares to
write the handling utilities. In fact, adoption would be gradual...
> 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.
The idea is: A clean data model + try to keep comments (even if they get
shaked a bit). A <comment> tag will work most of the time.
> 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 into 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.
You lost me. They are all kinds of configuration settings, why would one
want to handle them diferently? I still think that the XML view of the file
should include everything.
> > 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.
I like transpaerent systems more.
Reply to: