Get APLawrence.com by RSSText 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: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw98bk/html/inifilesversusregistry.asp
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.
;
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. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
I sell and support
Kerio Mail server
Click here to add your comments
---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.name=WWWHomePage
key.dict.key=ic-data
key.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
---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.name=WWWHomePage
key.dict.key=ic-data
key.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
---December 21, 2004
---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.name=WWWHomePage
key.dict.key=ic-data
key.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
---December 21, 2004
---December 21, 2004
---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.name=WWWHomePage
key.dict.key=ic-data
key.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
---December 21, 2004
---December 21, 2004
---December 21, 2004
---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.name=WWWHomePage
key.dict.key=ic-data
key.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
---December 21, 2004
---December 21, 2004
---December 21, 2004
---December 21, 2004
---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
---December 21, 2004
---December 21, 2004
---December 21, 2004
---December 21, 2004
---December 21, 2004
---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
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar