A recent Java magazine column by someone that I know is respected in the field (name slips me, unfortunately) had a recent article on using Windows .INI-like files as application initialization files, and proceeded to discuss the ways of reading and writing such files in Java. The next month, the same author had a followup column, starting off that he recently a lot of email lambasting him for not using XML; the followup column was how to use the same ideas in Java but using an XML-based system.

Now some opinions :-). I think a lot has to do with what you expect your config structure to look like and what you expect your audience to be able to use. Are you mostly just initializing a hash of items? Appconfig is probably the right choice. Maybe you expect that users should have an easy time of changing the config file, again making appconfig better. Right now, Appconfig config files are probably not hard to understand, while XML may be; however, in the near future, I'm sure we'll see tree-based editors that make the handling of XML editing very easy and thus making an XML file a better choice.

But more importantly: Why not include both? XML::Simple is sufficiently smart enough that if it immediately recongize the file as XML, it will die out, and this allows you to drop through to Appconfig. XML::Simple is sufficiently lightweight to not pose a big problem in terms of CPU and memory use on your apps. The only major concern is that you might have to massage the returned hashes from either XML::Simple or Appconfig to make sure that you are working with the same hash structure from each.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

IMO, XML is too verbose for configuration files meant to be edited by humans. If the config will only be read/written by another program, then it really doesn't matter what format it's in.

One of the most irritating things to me about XML configuration files is that a key/value pair can be expressed as an attribute or an element without any loss of information. I don't think that TMTOWTDI should apply in configuration files :-)

I think the INI format strikes the best balance among compactness, readability and expressiveness. I'd venture to say that anyone who would be editing a configuration file knows the format, and it's very simple to edit.

The other end of the spectrum is serialized (via Data::Dumper or Data::Denter) Perl data structures. These are extremely expressive, very compact but readable only to folks who know Perl fairly well. Depending on your audience the cost of this can vary.

Because of their expressiveness, Perl data structures also have the tendency to lull you into putting very complicated data structures in your configuration. IME, this eventually winds up biting you in the rear.

Chris
M-x auto-bs-mode

In normal use the application read and wrote it's own configuration setting, and users never touched the configration directly. When this worked, it worked fine the system started okay, ran okay and stopped okay. So in an ideal world I don't think it matters what you do, as long as your applications know what they are doing.

When things went wrong, it required a manual hack to fix things. Working on the Windows registry was something our customers were very unhappy to do. They worried that they would break everything. The simple XML file had it's advantages, over the more complex Windows Registry solution.

I find XML easy to edit by hand, and I use a dedicated XML tool, so I know if the file is well-formed, and if I'm lucky valid. Many people don't have the luxury of dedicated XML tools, and so I lean more towards a simpler text - if you expect people to edit them by hand.

What I would recommend more than anything else is the ability to run a sanity test of the configuartion file. One of our products wouldn't start if the XML file was invalid, and because the XML file was invalid, it wouldn't log that there was a problem with the configuration file. Apache has it's "-t" option which is most useful in testing that there is a config file, it can read it, and it's syntatically correct.

In my experience it doesn't matter how you do it when it works, but when it breaks you may need a solution that you can fix by hand. XML is okay, though it's not everyones cup of tea...

my 2p

Good luck....

I don't know about AppConfig, but commenting values in an XML file isn't that easy (or if it is, please show me how to do :).

In a few XML config files I have, I enter additional key-value pairs just to keep them commented. That's an obvious workaround I'd like to avoid.

/J

This is a very good point. One of the other major problems I have (besides those noted above) with reading and then re-serializing Perl data structures is that you lose all comments. When I wrote (yet another) INI parser for OpenInteract I borrowed the logic from Config::IniFiles for keeping the comments with the appropriate block when the config is written out. Works great.

(Yes, I had very good reasons for creating another INI parser. :-)

Chris
M-x auto-bs-mode

In this way, while making AppConfig as default, we'll make great flexibility to configure applications.

--
Tatsuhiko Miyagawa
miyagawa@cpan.org