There are two ways to write configuration files. There is the simple way used by nearly all linux/unix apps, and most Java developers:
#this is a config file
key1 = value1
key2 = value2
key3 = value3 #comments can go here
Then there is the crazy XML way that seems to be the preferred .NET method:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="key1" value="value1" />
<add key="key2" value="value2" />
<add key="key3" value="value3" />
<!-- comments are not fun at all -->
</appSettings>
</configuration>
I don’t know about you, but personally I think the first format is clear, concise, easy to read, easy to edit, and easy to document with inline comments. The second one is none of the above.
Both are easy to parse – especially since you will rarely need to do it by hand, as most environments provide classes that will do this for you. Maybe I’m old school but I think that simplicity of the non-xml config outweighs any potential benefit of using the xml markup.
At the end of the day most configuration files are just simple lists of key and value pairs. You don’t need XML’s tree structure to represent that. Very rarely do these pairs need to be ordered in a specific type of hierarchy that would warrant the use of XML.
For me, using xml for your config files is just meaningless overhead. Same information could be stored in a simple delimited text file. Of course if your platform has a built in support for XML config files, then that’s probably what you should use. But given a choice, without platform support for either format I would always pick simple text over XML.
How about you? Do you believe in XML config files?
[tags]xml, config, config files, configuration, configuration files[/tags]
Being a Solaris junkie, I have become accustomed to XML config files. Yeah, I like the older style when hand-editing, but XML parsers are efficient and easy to use.
I rank this right up with NIS vs LDAP. Sure, NIS was easier when editing by hand, but LDAP is so much more powerful and easier to use once it is deployed.
Yeah, but how much “power” do you actually get from using an XML structure for what is essentially an unstructured 1-to-1 pairing of keys and values? With LDAP there are some tangible benefits you can point to.
With XML config files – not so much. I find that often XML is used where a simple text config would be more appropriate, because… Well, because XML is cool. :P
Well, XML is more than that. It give you the ability to store data in a tree instead of a flat namespace. Sure, there are ways to represent that kind of data in a flat file, like an LDIF file, but XML does what it was intended to do.
I guess this is turning into a “vi vs emacs” type of battle . . .
I’m not disagreeing – XML can be very good for storing some types of configuration files. For example, the application list for InstallPad is a good example when XML as config file works well. This sort of data lends itself to be structured as a tree, and storing it as a flat file would be inappropriate.
But then again I see people using XML files to store stuff such as username, password, server address, and resolution settings for single application. Stuff like that could be stored as 4 lines of text, but instead we have 14 lines of XML.
I’m not against using XML – I’m just against using it where a simple file would do just as well. For example when you develop a new application and you are deciding how to structure your data file, XML may not always be the best choice.
But if your current platform, IDE or application suite natively supports XML config, then using anything else would probably be silly.
:)
I only use XML files for configuration.
I develop web apps in Flex and reading an xml file is just as easy as typing the URL to the file :)
It then is available as an Object with all the data parsed into appropriate data types.
Since Flex 2 is strong-typed, this is a major advantage.
When I use java I usually just use simple flat files. Then all I need to do is initialize an input stream to the file and pass it to the Properties class. It will do the rest and store all the values internally as a hashmap. :)
Of course all the values are considered generic objects so you will need to do some casting. I guess I can see how XML would be useful here – ie. you specify the data type of the key and etc.
I didn’t have an opinion until about 10 seconds ago, but when its as simple as a series of “key = value”s then the extra fluff around the edges seems pretty pointless.