Re^4: Config Files in Perl

[Firefly258]

You should be programming away from bad/worst case scenario not around assumptions about the end-user.

XML sure is terse and unweildy, no matter whether a human is used to it or not, the chances of things going wrong as a result of a "configuration error" when manually editing XML are high.

However, in the day and age of RAD, it's wise and definitely feasible to have a UI manage and maintain the configuration file(s), XML or otherwise.

[traveler]

XML sure is terse and unweildy, no matter whether a human is used to it or not, the chances of things going wrong as a result of a "configuration error" when manually editing XML are high.

Hmmm, I think I disagree. I think with a well-written DTD, XML configs are significantly less error prone than lots of lines of name=value.

This has got me very interested. Maybe it should be a subject for a Meditation and/or some research...

[chromatic]

How many humans do you know who will adhere to the strict interpretation of a DTD when modifying a configuration file? I like to think I'm pretty good with computers, and I might glance at the DTD, but I wouldn't keep it in hand.

[Firefly258]

XML might work if it was well-formed and laid out neatly as per a custom DTD, but that's just extra hassle for the sakes of getting XML to work.

Furthermore, I have seen some weird XML configuration files that go along the lines of this (forgive me if this isnt valid XML, it's only a crude example).

<xml>
 <file1 perms="rxwrwxrwx" contents="invoices for the month of may">/pa
+th/to/some/file1<file1>
 <file2 attributes="hidden from floor staff" expires="Mar,2007" conten
+ts="company downsizing plans">/path/to/some/file2<file2>
...
</xml>

That opposed to the micro$oft .INI fmt


[File1]
File=/path/to/file1
Perms=rwxrwxrwx
contents="invoices for the month of may"

[File2]
File=/path/to/file2
Attributes="Hidden from floor staff"
Expires="Mar.2007"
contents="company downsizing plans"

The latter not only looks neater, information is easily gleaned out of it when a human reads it. Less is likely to go wrong with it too, IMO and (Tongue in cheek) it also takes up less disk/memory space. :)

Well, I'm a fan of XML (for various reasons) if it's machine-generated and machine-read, I'd consider it in in-house config-files (as long as staff were XML-savvy), but if I wanted to save support staff the headache of dealing with an external XML-unsavvy user, I'd use .INI or something along those lines. XML is just not worth the hassle if you are going to have other people meddling about with it.