Le dim 19/10/2003 à 18:59, Konstantin Riabitsev a écrit :
On Sun, 2003-10-19 at 12:24, Nicolas Mailhot wrote:
> Sure - however xml is getting more prevalent and even if it's not the
> easiest format to grok for a human it's always easier than learn
> yet-another-config-file format.
Win-ini style config is really easy to learn and edit:
[section]
variable = value
> Really if one doesn't forget to put comments in the file, use strict dtd
> checks so the app can tell on startup what errors were made, does not
> forget to indent properly its file and uses a logical namespace xml can
> be a joy to read. People do forget xml "verbosity" is here to help human
> readers.
There are several significant drawbacks to using xml for config files.
Here is an incomplete list:
1. Having to escape values.
<foo>
You have to make sure that all <, >, & and " characters
are escaped, otherwise your config file will break. Reading content
with escaped characters is NOT easy or simple, or obvious.
Alternatively, one must use <![CDATA[Even less obvious "CDATA"
constructs, which allow <>&, but are questionably better]]>
</foo>
Which is fine and nice to say for non-i18ned stuff.
In real life win.ini-style files fail in strange and wonderful ways when
one uses non-english comments/data
(of course it all depends on your data, if you need lots of <, >,
& XML can be a PITA)
The " is a non-problem unless you are abusing attributes to get
long textual descriptions.
2. Having to watch your comments.
<!-- <foo>
This section has been commented out and is fine.
</foo> -->
<!-- <foo>
<!-- This section does foo -->
This section has been commented out, but is illegal, because it has a
nested comment inside.
</foo> -->
<!-- <foo>
This section has been commented out, but it is illegal -- it has a
double dash in it, which is not allowed inside a comment.
</foo> -->
It is very important for a sysadmin to be able to comment out parts of
some config files. It quickly becomes very irritating if they have to
constantly make sure that there are no nested comments inside these
config files, or that there are no double dashes used anywhere.
This one is a little pain, right.
Most modern text editors however grok xml, will do syntax highlighting
and show where comments start/end.
3. Keeping your DTD/Schema definitions current quickly becomes a
burden.
You can't just add a new configuration directive -- if your app relies
on DTD checking for validity, you then have to edit your DTD.
So what ? If you are advocating skipping checks to save development time
I disagree. I've been bitten enough times by apps that behaved in
strange way because they "saved time" by not checking their conf file
validity, and I made a typo.
We are talking about people changing stuff in the files manually. Saving
on checks won't do them any service.
My rule has been:
1. If the config file can be expressed in simple section/variable/value
pairs, then use win.ini-style config files. They are easy to read, easy
to edit, and they don't require extra effort to keep valid. If, however,
that is not sufficient to express your config, then use XML. Let's face
it -- most config data is just assigning values to variables, and for
that XML is an overkill.
I more or less agree with you except my threshold to switch to xml is
much lower (ie use flat files for flat short ascii name-value data, even
a single section-level hierarchy justifies moving to xml).
Suppressing checks won't help users. Writing your own check system is
more painful than using dtds/schemas.
If you have enough entries your file could be made more readable by
adding hierarchy.
Most text editors are more and more xml-aware when other formats have
reached a ceiling long ago. A good xml mode can provide contexts, hints
etc.
smb.conf is a perfect example of win.ini hell.
java .properties are another example of flat-files retrofitted to host
hierarchical data without consideration for humans.
Cheers,
--
Nicolas Mailhot