Configuration Files | Applied XML Solutions

Most applications use some sort of configuration files to store information such as paths, window sizes, user preferences, and network addresses.

Because configuration files are so important, most programming languages, including Java, have built-in support for them. In Java, this support takes the form of the java.util.Properties class. Windows and other platforms use the ini files. Windows also has the Registry.

With the exception of the Windows Registry (which has other problems of its own), most configuration files are flat text files. They store a list of properties similar to the following:

 #  @(#)flavormap.properties     1.5    TEXT=text/plain;charset=ascii    UNICODE\  TEXT=text/plain;charset=unicode    HTML\  Format=text/html;charset=unicode    Rich\  Text\  Format=text/enriched;charset=ascii    HDROP=application/x-java-file-list;class=java.util.List

In practice, many applications would benefit from a richer structure. Consider the following extract from a Web server configuration file:

 SERVERS : main    main.CLASS : com.mortbay.HTTP.HttpServer    main.STACKS : root    main.PROPERTY.SessionMaxInactiveInterval : 3600    main.PROPERTY.MinListenerThreads : 10    main.PROPERTY.MaxListenerThreads : 0    main.PROPERTY.MaxListenerThreadIdleMs : 0    main.LISTENER.all.CLASS : com.mortbay.HTTP.HttpListener    main.LISTENER.all.ADDRS : 0.0.0.0:8080    main.root.PATHS : /    main.root.HANDLERS : file    main.root.file.CLASS : com.mortbay.HTTP.Handler.FileHandler    main.root.file.PROPERTY.FILES.FileBase.PATHS : /    main.root.file.PROPERTY.FILES.FileBase.DIRECTORY : ./docs

Obviously, these properties are organized in a hierarchical format. For example, main.root.file.CLASS and main.root.file.PROPERTY are related to the same process within the server.

This chapter is a manifesto to encourage you to use XML as the preferred format for serious configuration files. But it won't stop there. You will also explore how (and when) XML lends itself to building a mini-script language.

Scripted Configuration Files

Take the example of an online survey application. Online surveys are popular, and Web sites are struggling to come up with imaginative surveys. The survey in this example measures interest in books on XML.

Imagine a survey engine. It presents questions to visitors and collects the answers. Most questions are simple, simply requiring the visitor to pick the answer from a list of choices. However, some questions can be open -ended, requiring the visitor to type his choice.

The list of questions will typically end up in a configuration file to make it easy to edit. Obviously, XML is a good choice because it will support the relationship between the questions and their choices, as in the following:

 <?xml version="1.0"?>   <survey>      <question>         <label>Do you use XML?</label>         <choice>            <option>               <label>I do</label>               <value>yes</value>            </option>            <option>               <label>No but I plan to use it</label>               <value>planning</value>            </option>            <option>               <label>No and I don't plan to use it</label>               <value>no</value>            </option>         </choice>      </question>      <question>         <label>Do you need more XML books?</label>         <choice>            <option>               <label>Yes, I would like more XML books</label>               <value>yes</value>            </option>            <option>               <label>No, I have all the books I need</label>               <value>no</value>            </option>         </choice>      </question>      <!-- more questions deleted -->   </survey>

In all but the simplest survey, questions are linked to each other and the answer to one might determine which question is asked next . For example, if the visitor has no plan to use XML, it does not make a lot of sense to inquire whether that visitor would be interested in an XML book. Move to another part of the survey instead.

How should you represent this linking in the configuration file? Again, traditional configuration files are ill-equipped for this, but, with XML, you can build a nice answer: a scripted configuration file.

A scripted configuration file can store some of the logic, such as how to decide on the next question, in the configuration file. It takes the form of a simple script, such as

 <if>       <eq>          <answer>usingxml</answer>          <text>no</text>       </eq>       <text>done</text>       <text>morebook</text>    </if>

If the visitor replies that he is not using XML, the survey is complete. Otherwise, you inquire about more books.

Why Not a Real Scripting Language?

Why ponder on this hybrid, the scripted configuration file; why not adopt a real scripting language? After all, ready-made interpreters are available for the most popular scripting languages, such as VBScript, JavaScript, Tcl, Perl, and Python.

Scripted configuration files are a middle ground between a full-blown scripting language, which is intimidating for many users, and a non-scripted configuration file, which is often too limited.

Furthermore, interpreters tend to be large. Because they support a full-blown language, they offer many options at the cost of being larger and more complicated to use.

In other words, scripted configuration files strike the right balance between complexity and usefulness for many projects. As you will see, building them in XML is not difficult.

Finally, users can take advantage of many XML tools, including editors, to help them prepare the configuration files ”and it does not require more work from you.

For completeness, I must stress that this does not replace your favorite scripting language. For heavy-duty programming, adopting a real scripting language makes more sense, if only because you will benefit from standard libraries and other facilities.