http://www.perlmonks.org?node_id=585640


in reply to Re^2: Config Files in Perl
in thread Config Files in Perl

They might. OTOH it might all be done by software. That wasn't specified.

Now, I agree that XML is not beautiful, but so many people who might edit config files probably are at least somwehat used to HTML, and even vim knows XML highlighting. I do not think it is a problem unless the config file designer goes wild...

Replies are listed 'Best First'.
Re^4: Config Files in Perl
by Firefly258 (Beadle) on Nov 23, 2006 at 07:29 UTC
    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.
      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...

        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.

        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.