At what point does a config file become a programm

Question

I have been mulling over config files and their relationship to code for a while now and depending on the day and direction of the wind my opinions seem to change. More and more though I keep coming back to the realization I first had while learning Lisp: there is little difference between data and code. This seems doubly true for config files. When looked at in the right light a Perl script is little more than a config file for perl. This tends to have fairly heavy consequences for tasks such as QA and divisions of labor like who should be responsible for changing config files.

The creep from config file to full fledged language is generally slow and seems to be driven by the desire to have a generic system. Most projects seem to start out small with a few config items like where to write logs, where to look for data, user names and passwords, etc. But then they start to grow: features start to be able to be turned on or off, the timings and order of operations start to be controlled, and, inevitably, someone wants to start adding logic to it (e.g. use 10 if the machine is X and 15 if the machine is Y). At a certain point the config file becomes a domain specific language, and a poorly written one at that.

Now that I have rambled on to set the stage, here are my questions:

1. What is the true purpose of a config file?
2. Should an attempt be made to keep config files simple?
3. Who should be responsible for making changes to them (developers, users, admins, etc.)?
4. Should they be source controlled (see question 3)?

As I said earlier my answers to these questions shift constantly, but right now I am thinking:

1. to allow a non-programmers to change large chunks of behaviour quickly
2. yes, anything that is not coarsely grained should be in code
3. users should be responsible for config files and programmers should be responsible for a configuration layer between config files and code that gives more fine grained control of the application
4. no, but the finer grained middle layer should be

Answer 1

One of the purposes of the "Oslo" work at Microsoft is to permit (though not require) resolution of this issue.

1. An application would ship with models of any new components it includes. It would also use existing models. For instance, it might include a web service, so it could reuse the system model of a web service.
2. The models will include metadata describing them, including enough information for tools to access them, either textually or graphically.
3. Parts of the models will correspond to "configuration"

This means that the equivalent of todays configuration files may be rich enough to support both textual and graphical editing of their configuration. The graphical tool will be supplied with "Oslo" (code name "Quadrant").

Answer 2

I'm a big fan of using python programs as config files, especially for daemons. I like to take the tack of making the daemon completely empty of configuration except for the "configuration port". The python program then connects to the daemon and proceeds to create objects in the daemon and wire them together to create the desired configuration. Once everything is set up, the daemon can then be left to run on it's own. The benefits, of course, are that you get a full fledged programming language to write your config files and since you already have a way to talk to the daemon from another program, you can use it for debugging and getting stats. The major downside is having to deal with messages from another program coming in at any time.

Answer 3

I tend to agree with the premise of this question. I avoid getting myself into trouble by predicting early that this is going to happen, and therefore never roll my own config system.

• Either I use the operating systems' config facuility (such as a plist, or gconf or whatever is appropriate),
• Or a simple flat file, as can be handled by something like an off the shelf INI parser.
• Bite the bullet and plug a light weight language parser, usually lua, sometimes tcl into the application,
• Or store data in a SQLite or similar relational database.

And resign myself to live with whatever decision I made, or if i cant, refactor to use one of the above choices that better suits the application.

Point is, there's not really any reason to use a home-grown config solution. For one thing, it's harder on your users to have to learn a new, application specific config format. For another, You benefit from all the many bug-fixes and updates that come free when using an off-the-shelf solution. Finally, Feature creep is put to rest, because, well, you actually can't just add one more feature without really doing a major overhaul cause the config system isn't really in your hands in the first place.

Answer 4

Every (sufficiently-long-lived) config file schema eventually becomes a programming language. Due to all the implications you describe, it is wise for the config-file designer to realize she is authoring a programming language and plan accordingly, lest she burden future users with bad legacy.

Answer 5

I'll be the contrarian and submit it's only a language when it embodies more than can be represented by XML; or else when XML is considered to be a language.

Alternatively, most config files can be thought of as classes, but with only properties and no methods. And without methods, I don't think it's a language.

Ultimately, "language" is a squishy abstraction, but yes, the edges are ambiguous.

Answer 6

It depends on what you agree with other developers on the team. Are you using config files just as config files or you are creating a Model Driven application.

Symptoms of config file becoming a programming language:

• name=value pairs start to depend on each other
• you feel a need to have flow control (ex. if (this) than that)
• documentation for config file becomes essential in order to do further development (instead of just using the application)
• before value from config is read it requires to have some context (i.e. values depend on something external to config file itself)