Comments on: Plain Text Config Files are Confusing

By: she

she — Sat, 09 Feb 2008 01:45:15 +0000

Personally I have switched to Yaml for 90% of my projects.

It works nicely. Yaml is no panacea but it works nicely, is a LOT more readable than XML, and
does the job fairly well. I’d wish all scripting languages would support (and use) YAML like Ruby does,
this way I can know that all my yaml files will work in other languages too.

Instead of embedding info in a .rb file, I am embedding the info in a yaml file, which is a lot better to
not tie yourself to only one language. Think if instead of C .h files they would use yaml and provide nice
APIs to use from ruby easily… i am dreaming

By: David Myers

David Myers — Fri, 08 Jun 2007 17:38:02 +0000

I’ve been server support for large projects that indulged in overly complex undocumented XML file configs and what that tends to do is give the project developers another role: second tier production support.

By: Jonathan Feinberg

Jonathan Feinberg — Tue, 27 Mar 2007 10:51:13 +0000

The idea that using XML somehow gives you some canonical way of expressing settings is a kind of a strawman. Consider:

gnorf

By: Philippe Lhoste

Philippe Lhoste — Thu, 15 Mar 2007 15:56:59 +0000

> In both cases, theyâ€™re still advocating single, well-defined syntaxes with standard parsers.
> They are not advocating plain text config files.
> To the extent that their data formats are only for Ruby or JavaScript programs respectively, this makes some sense.

Some mentioned YAML.
Well, there is also Lua, the programming language, initially designed as a configuration language, and evolved to be a powerful multipurpose language, but it still well suited to data description.
The nice part is that it isn’t much bigger than an average XML parser, and can be easily integrated in another (compiled) language (C, Pascal, even Java) which can then access the result of parsing the configuration file by Lua.

By: David Smith

David Smith — Sat, 03 Mar 2007 20:18:32 +0000

I’m with Eric Raymond on this one - if humans maintain the file, it should be human-readable. Saying that there are ways to mangle XML so that humans can read it is very different from saying that they are “human readable”.

Suggesting that every implementation of this mangling does and always will produce the same result is touchingly naive. I can pop XEmacs 21 today and read archived 25-year-old dotfiles from one of my System V user accounts and know that I’m seeing exactly the same text that I created in vi in 1982. Predicting that the XML parser of the moment in 2007 will produce exactly the same results as the XML parser of the moment in 2029 is a leap of faith. Call me old fashioned, but it’s worked like a hot damn for a long time.

I’d also suggest that if you’re going to make a point about ascii text config files, you use one from a mature, well-written platform like almost anything in a BSD /etc directory, sendmail or Apache. None of them are “any-human-off-the street-readable” but they work wonderfully for a qualified admin, are readily searched and manipulated by a raft of different tools, and can easily be created and/or maintained programmatically.

I’m a huge fan of XML as a way to transfer data between disperate systems - I’m just not willing to make it the only tool on my belt.

By: Labnotes » XML configs files are your competitive disadvantage

Labnotes » XML configs files are your competitive disadvantage — Wed, 28 Feb 2007 03:38:27 +0000

[...] February 27th, 2007 Elliotte Rusty Harold: “Thereâ€™s a large rebellion over XML config files from programmers who donâ€™t like to type XML and donâ€™t want to learn APIs for processing it. Theyâ€™d rather limp along with the same scanf code theyâ€™ve been using for the last 20 years.” [...]

By: Adrian

Adrian — Tue, 27 Feb 2007 20:42:13 +0000

>A simple configuration file moving to a not so simple configuration file over an applicationâ€™s life cycle is more likely a symptom of a design problem in the application. It is better to revisit the application design at that stage.

What? Either you want/need to expose a lot of configuration or you don’t. Revisiting your design isn’t going to change that.

By: Adrian

Adrian — Tue, 27 Feb 2007 20:34:07 +0000

>>â€œWhat there is are specially formatted text files that are easily as complex as the XML equivalent but inconsistent, poorly documented, and easily broken”

> Yes and the idiot that decided to subject his users to this will achieve the same results with XML.

No, they can’t unless they write their own XML parser: XML has a specification, so it’s always going to be consistent.

>If your chosen language doesnâ€™t make it easy to robustly parse non-xmlian config files then maybe you chose the wrong language for the job.

I think the point here is that plain text config files *are* the wrong language for the job.

By: Brad Huffman

Brad Huffman — Tue, 27 Feb 2007 16:10:58 +0000

0. Documentation!

Why, O why is this one always left out.

By: Hammer&Nail

Hammer&Nail — Tue, 27 Feb 2007 15:40:02 +0000

A simple configuration file moving to a not so simple configuration file over an application’s life cycle is more likely a symptom of a design problem in the application. It is better to revisit the application design at that stage. Or put it other way, configuration file is a resource and not a kitchen sink junkyard for things which the programmer has not figured out where to fit. Treating it as a resource is the solution.

Also reading from the above responses, the argument for an XML based config file is going the way of “4 spaces vs. 2 spaces vs. tabs” argument!

Is Elliotte trying to pick our brains to see how an ideal configuration looks like? Here are some of my points:

1. Easily readable, understandable and “operatable”. Think of the overworked IT operator or an overwhelmed user trying to modify the config file.
2. Understand your target audience!
3. Minimalistic. Do not make it a kitchen sink!
4. Think building blocks.