Text Configuration files and XML


More Articles

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


Hate these ads?

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.



Comments /MacOSX/configxml.html


Add your comments




Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Or use any RSS reader

Delivered by FeedBurner





Views for this page
Today This Week This Month This Year  Overall
117313 4,087

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.

Publishing your articles here

pavatar.jpg
More:
       - MacOSX
       - Programming




Unix/Linux Consultants

Your ad here - $24.00 yearly!

larryi@ccamedical.com SCO OS5, Debian Linux, RedHat Linux, MySQL, Apache, AJAX development using dXport/dL4/Unibasic, Windows Connectivity, Sharing Resouces, Automation, Shell Scripting


http://www.loch-raven.com/Loch Raven provides consulting services for Linux, UNIX, SCO OpenServer, SCO UnixWare, AIX, Solaris and FreeBSD systems. Services include: System administration, Backup and Disaster Recovery planning and implementation, Custom Shell Scripting, System Recovery, Remote Administration, Secure Remote Access configuration, Troubleshooting, System Migration and Windows/Linux/Unix integration with Samba. Loch Raven also provides web site hosting, solutions, and consulting along with Joomla CMS.


UBB Computer Services Support for Openserver, Unixware and Linux. Windows integration with Unix/Linux servers. Hardware, Backup and Networking issues. Located near Sacramento CA, we provide onsite support throughout Northern CA and Nationwide via remote access. We are a SCO Authorized Partner and a Microlite BackupEdge Certified Reseller.









Change Congress


Related Posts