Repository feature proposal

[Nicolas Mailhot]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031019/2f8d838b/attachment.sig>