Configuration

A running computer application is said to be in a state, which is defined by the set of all the variables in its current working space at any instant of time. An application runs from one state to another as any information within its initial or current state changes. This is possible either as a result of an expression or by providing data to the application externally [117]. Sometimes an application is required to halt its execution and continue at a later time, starting from whatever the state it was in when it stopped. In such cases, states can be saved and re-initiated by storing all the variables of a running application, and bringing recalling them back to the memory at a later time. These recorded states are simply serializations of current memory used by the application. In addition to altering states during execution, either human beings or other applications get a chance to change an application’s state by modifying serialized values when the application is interrupted.

Application users can also control program states by providing input parameters to applications during start-up. This gives applications mobility and portability, which increases the likelihood that users will adopt them into their environments. Input parameters can be given on the command line or in a file. Files that contain a set of initial values are called configuration files. They are parsed and read into the memory, and initial values of variables are set.

File Formats

Binary Files. Applications that are capable of serializing their current states can store information in binary format, an exact representation of the data stored in computer memory. This method provides for very fast storing and restoring operations; however, users lose the ability to alter the states by means of simple editing tools.

Flat Files. Many configuration file formats have been developed; however, simpler ones survived. The simplest file format is the flat structure of name and value pairs [Figure 2.4(a)]. In this format, each value is associated with a name, that is later used to retrieve its value. The advantage of this format is that it is very simple to read and change names and initial values with widely available text editing tools. It also does not require advanced programming skills to write a parser for this file structure.

As the size of a configuration file increases, flat files cannot express complicated groupings. The ability to manage a file and to alter its content becomes difficult.Readability is lost. Any addition of new name and value pairs that might be needed with new versions of programs might require modifications in the source code where maintenance costs are high compared to other phases of systems development.

Some attempts were made to use a tree model in configuration files such asaddition of sections by Microsoft WindowsTM [Figure 2.4(b)]. With this addition,developers could access values with three parameters, the first being the section name and the others are name and value pairs. Another attempt has become popular with JavaTM programming language property files [Figure 2.4(c)]. In these files, developers use the same old flat files, however, key names started to resemble a hierarchy. In this method, each name can be broken up into pieces so that each part represents a level in the hierarchy and a relationship between its parent and child names, where names usually are of modules. 

Whether for serialized application states or configuration files, any file format that requires human interaction or data exchange would be more advantageous if it is structured in a tree format. Relationships such as parent-child, component-container,and inheritance between real-life objects as well as computer-generated objects such as windows, buttons, processes, graphical objects, are all hierarchical. XML as a file format brings advantages not only for the presentation of data and relationships, but also for configuration file processing and error handling [Figure 2.5].Advantages of using XML for configuration are discussed in detail in [78] and in[48]. In summary,

• XML for configuration brings a unique format for both users and developers where users do no need to learn different formats and developers do not need to write a different parser for each format they adopt. Freely available parser scan easily be embedded in development cycles.
• A common schema can be used along with third party XML software or a schema specific administration tool to write and validate configuration files, before feeding applications, which significantly reduces the amount of error handling, development work, and application execution time.
• Default values can be supplied by a parser from a schema or any other content model. Any changes due to new versions can be backward compatible by providing defaults in a similar fashion, which does not require programming or recompiling. Another option would be using an XSL transformation froman old version to a new one without additional programming.