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
Attachment:
signature.asc
Description: Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=