Visual Basic Instinct : A Better Configuration Parser

A Better Configuration Parser

In this article, I will present the inherent problems in traditional configuration files, and present a configuration parser that extends the concept of configuration beyond the file.

Previous times

Initialisation files

Some of you will remember Windows 3.x, where initialisation files played an important role in storing an application's configuration. Although Microsoft had begun planning the registry, a typical installation of Windows had ini-files scattered all over.

Ini-file structure is simple, and sometimes very restricting. It's built on sections. Each section has a unique name, and contains keys. Each key has a value, and several keys can have the same name. In querying for a value, you must supply section name and key name.

The disadvantages to this format are numerous. You cannot have nested structures, since sections inside sections aren't allowed. This calls for a flat layout, which is sometimes impractical. Section definitions have no end tag, so if a section start tag goes stray, the keys will silently fall into another section's scope.

The Registry

With Windows 95, the registry made its first public appearances. Microsoft had realised that the limitations of ini-files were an obstacle for developers, and they wanted to improve on it. The registry has some advantages over ini-files; for instance, you can have nested structures, and Windows will do some magic on user logon so that the section relating to the current user will be loaded with that user's configuration automatically.

However, the registry has its disadvantages too. It's stored in a binary format, leaving it vulnerable to corruption. In system critical environments, fail safe formats can be a top priority to developers and technicians. Under heavy pressure, the registry can be slow and irresponsive. From a VB developers view, the registry is easy to access using GetSetting/SetSetting, but that will leave you with no control of where in the registry the data is actually stored. If you want control, you will have to use the API.

Did I Say File?

Sometimes, you don't want to store configuration in a file at all. Database clients may have much of their configuration stored in the database itself, so both ini-file or registry functions will require you to read the settings from the database, write them to a file, and then read them back. Impractical, to say the least. There are numerous applications for non-file storage, yet Microsoft seems to ignore this completely.

The Configuration Parser

In recent projects, I've needed a fast, fail safe, flexible, and storage-independent format for storing my configuration data. It was imperative that the configuration data was easy to edit with a text editor, and that a technician would be able to recover the data easily in case of system failure or data corruption.

The Format

I invented my own format. It's not very hard to understand - people with experience from Linux will recognise it as a common format for configuration files for Linux utilities - it's reasonably robust, and it's easy to parse. Here's a quick sample:

# This setting tells the application where to write log entries
LogFile "C:\Log Files\Today's log.txt"

<Database>
	Provider SQLOLEDB
	DataSource (local)
	UserId admin
	Password test
	Catalog MyDB
	
	<MoreInfo>
		SomeMoreInfo "on this subject"
	</MoreInfo>
</Database>

Notice how a section has both a start and an end tag, and how key values can be quoted or not quoted. Sections can be nested, and key/value pairs can be placed outside sections. Even comments are allowed if you prefix them with a hash. An attempt at a more formal specification is distributed with the source code.

The Notation

The sections of a configuration text form a tree, with all key entries outside of a section belonging to the root. Naturally, the notation to address a key inside this tree is on the following form:

/section/section/section/key

With the configuration parser, you can address an entire section or a specific key. In either case, you will end up with an object whose properties you can read or write. The entire configuration can be investigated if you address the root section and enumerate sections and key from there on.

The Storage

The configuration parser will accept input either as a string or from a file. The file option is actually just a shortcut, since this is the most obvious data store; the string parser is called either way. Just as with ini-files, a configuration file can be stored in the application's directory or in the Windows standard folders; it cannot, however, be stored randomly in the path, but this feature could be included later.

Writing a Configuration

If you want your application to generate a configuration string, you will have to build an object structure similar to the one that is generated when a configuration string is loaded. Each section has methods to add other sections or keys, and the component itself has a method to generate the configuration string based on the current object structure.