Michael Stenner wrote:
I'll use this, since it's much easier to quote. :)
> Let me try and summarize your five points:
>
> a) a standard config format would be good, and xml would be a good
> choice for that
>
> b) xml is well understood, other formats are inconsistent (maybe this
> should be a.1)
>
> c) xml is extensible, or MUCH easier to make extensible than
> most hand-rolled alternatives
>
> c) [ you probably meant d :) ] xml is easy to edit by hand
>
> d) easy multi-purpose parsing and machine-editing
I've worked with XML extensively in the past 4 years, and when it
comes to using xml in config files, I have formed the following opinion:
Use XML only if a simple (section->)variable->value format is not up
for the job. Here are the reasons.
1. Visual simplicity
This is the top and foremost reason to use the "win.ini" format. E.g.:
[mysection]
foo=bar
baz=quux
This is very easy to grok visually, because it limits the formatting
symbols to just a few. You can see clearly the section name, the
name of the variable, and the value that is assigned to it. The same
data in XML would look like so:
<config>
<section id="mysection">
<set>
<variable>foo</variable>
<value>bar</value>
</set>
<set>
<variable>baz</variable>
<value>quux</value>
</set>
</section>
</config>
It is very hard to quickly make out the following information:
a) Name of the section
b) Which one is the variable name
c) Which one is the value
All config files need to be edited by humans, and therefore they all
need to be visually simple for a human to figure out (and figure out
quickly, if the configuration is critical for some reason).
2. Parsing simplicity.
I have written parsers for this file format for php, bash, and perl.
It's really straightforward.
3. Commenting out code is simple and visually effective.
Comments are either "#" or ";". It is easy to see which line is
commented out and which line isn't. In XML it is by far more
complicated. Compare:
[mysection]
foo=bar
baz=quux
#bogus1=blah
#bogus2=blah
qez=zeq
#bogus3=blah
vs.
<config>
<section id="mysection">
<set>
<variable>foo</variable>
<value>bar</value>
</set>
<set>
<variable>baz</variable>
<value>quux</value>
</set>
<!--
<set>
<variable>bogus1</variable>
<value>blah</value>
</set>
-->
...etc...
</section>
</config>
Comments in XML also have certain important limitations. E.g. if I
can use a comment-within-a-comment using "#" or ";", I can't easily
in XML. This is perfectly legal:
# Commented out
# foo=bar
# # Commented out previously but left dangling
# # baz=quux
#
This isn't:
<!-- Commented out
<set>
<variable>foo</variable>
<value>bar</value>
</set>
<!-- Commented out previously
<set>
<variable>baz</variable>
<value>quux</value>
</set>
-->
-->
This is illegal because well-formed XML cannot have "--" inside a
comment. This means that if you want to quickly comment out a large
section of your config, you will have to keep in mind this important
tidbit, otherwise your XML parser will bail, most likely with a
non-descriptive "Document not well-formed" error, leaving you
scratching your head and painstakingly going through your config
file, until you realize that the error is caused by a double-comment.
There are other reasons why XML is not suitable for the vast
majority of config files, but I'll stop on these three, as this
email is quickly becoming Rob-like.
HOWEVER, having said that, if win.ini-style is not suitable for
config files, I would STRONGLY advocate using XML for creating one,
vs. coming up with a yet-another-config-file-format, and this is
simply because for complex structures that still require being
user-editable there is nothing better.
In the discussion relating to the point at hand -- a file for yum
templates, this largely becomes a moot point anyway, primarily for
the following reasons:
1. Yum template file isn't a config. I.e. it doesn't define how
software operates: it is a set of operations for yum to perform, and
is therefore a data file.
2. Win.ini-style config file is not suitable for this, as has been
made obvious to me by Seth in an IRL conversation.
3. Template files are likely to be extended in the [possibly near]
future, with addition of such stuff as key-signing, etc.
Keeping these points in mind, I would actually advocate picking a
simple/sane XML file format and going with it. XML exists for
representing complex data structures with the help of human-editable
Markup Language, which may in the future require eXtending, so it
seems to me that it is actually the best choice for the job.
Writing yet-another-config-file, e.g. using %silly delimiters might
quickly backfire if only for the same reasons why I can no longer
write "cleaned up %post" in the spec-file changelog entries. ;)
Regards,
--
Konstantin ("Icon") Riabitsev
Duke University Physics Sysadmin
www.phy.duke.edu/~icon/pubkey.asc
