APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Text Configuration files and XML

Configuration files are a problem for both operating systems and applications. Where do you keep them, how are they structured?

Traditionally, Unix systems used text files with wildly varying internal structures, and Windows used either binary data or ".ini" text files (in this sense, "binary" is used for anything that you can't access directly with a simple text editor). More recently, Windows abandoned .ini files in favor of a binary central registry.

The benefits of using a simple text format for configuration files should be obvious: nothing to learn (assuming that you can figure out WHAT to edit), and far more robust - no internal pointers to get screwed up, etc. The downside is that reading these files is slower, but realistically that is almost insignificant. There is also the annoyance of converting any required binary values to and from text, but again, that shouldn't be anything that really slows down the reading or writing.

However, the ease of editing can be seen as a disadvantage also: if a proprietary tool is necessary for accessing the files, you can impose consistency checks and possibly avoid the introduction of garbage.

I lean toward text files. It is possible to provide validation tools that CAN be used, and even SHOULD be used under ordinary circumstances, while leaving the ability to directly edit raw text when circumstances are not ordinary. A good example of that philosophy is the "visudoers" command (see http://aplawrence.com/Basics/sudo.html ). You should use visudoers ordinarily, but if for some reason you could not, you can edit the /etc/sudoers file directly. Some systems provide special editors for the /etc/passwd file for the same reasons, and of course your normal "editing" of that is through other tools like "useradd" etc.

However, the structure of text configuration files is still a problem. Everything has its own format: /etc/passwd is nothing like /etc/sudoers and neither have any resemblance to /etc/fstab. There's no common structure. Unix generally ignored this problem, but Windows tried ".ini" files to impose some consistency. Unfortunately, the .ini format doesn't really cut it, because it's just too simplistic. There have been some attempts to extend .ini to allow nesting and other features, but most agree that it just doesn't have legs and isn't a good solution. Windows didn't drop .ini files entirely (they couldn't, simply because of legacy concerns) but they did strongly discourage their use and also provided some integration of .ini into the Registry: Why are INI files deprecated in favor of the registry?

With Mac OS X, Apple has taken a different approach and uses XML property lists for most configuration data. Using XML provides a consistent data format that is easily hand or program edited.

For example, here's the start of my ~/Library/Preferences/com.apple.internetconfig.plist:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 

If we look carefully, it's easy enough to find the home page setting there:

       <key>WWWHomePage</key>
            <dict>
                <key>ic-data</key>
                <string>http://www.pcunix.com/index.html</string>                              
            </dict> 
 

and, of course, many other settings and preferences. Every Mac OS X app uses XML property lists too; see http://aplawrence.com/MacOSX/twosafaris.html for an example of those. Apple doesn't suggest you edit plists directly, of course: there are tools for setting preferences and you should use these whenever possible. But knowing that I can edit these files easily gives me more confidence in my ability to diagnose and fix problems.



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Text Configuration files and XML

1 comment



Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Tony Lawrence




---December 21, 2004

The article states:

"Unfortunately, the .ini format doesn't really cut it, because it's just too simplistic. There have been some attempts to extend .ini to allow nesting and other features, but most agree that it just doesn't have legs and isn't a good solution."

Hogwash. If you want to have nesting in an INI format file, just make the nesting explicit in the attribute name.
As an example, we can easily rewrite the sample Mac XML plist thus:

key=WWWHomePage

dict.key=ic-data

dict.string=http://www.pcunix.com/index.html

Short and sweet, and easy to parse for machines and humans.

The level of nesting in any config file rarely goes any deeper than about 3 levels (and frequently, there no nesting at all), so this explicit nesting scheme should not prove burdensome. It also makes it easier to tell a layperson exactly and unambiguously which line he or she should edit, rather than having to explain the structure of XML blocks, which is what one would be forced to do otherwise. K.I.S.S.

This style also makes it easy to specify list values in a compact and straight-forward way for laypeople, as below:

crt.refreshrate=60,75,85




------------------------
Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





We're terrible animals. I think that the Earth's immune system is trying to get rid of us, as well it should. (Kurt Vonnegut)





This post tagged: