How to Distinguish Configuration from Code

The post about "Active Configuration" by Brian McCallister got me to revisit my thoughts on configuration.

To begin with, should there be any differences between code and configuration? Where is that line that dilineates the two? The lines between configuration and code tend to be drawn between the target audience. That is, it is designed so that the administrator sees a different view as a programmer. In addition a more restrictive environment is provided (i.e. you can't write arbitrary code in the config file). However, for most software there is more than one target audience, this could lead to an explosion of configuration files.

Compounding the problem is that the target audience will vary depending on context. A Java Bean configuration usually isn't exposed as a configuration that is available to the administrator of a system that embeds that bean. However, some subset of the bean as a configurable property shouldn't disallowed.

Stuart Halloway wrote a piece "Properties Purgatory" expressing his dismay of the chaotic state of standard Java configuration. He presented this table:

	Java platform	JNDI CCI	Security CCI	RMI CCI
Structure	Java language	properties file	custom format	properties file
Lookup	classpath, custom loaders	ad hoc rules	ad hoc rules	system props only
Scope	static, instance, class loader, others	poorly specified	poorly specified	poorly specified
Metadata	binary class format, reflection	none	none	none

that highlighted how the Java platform is rich enough to handle many of the features that a good configuration should have. So, this brings up the question, if Java is good enough, well then why not use Java for configuration? Even more general, why not use code for all configuration?

This idea isn't really new. In Lisp, all code are lists and all data are lists. In Mozilla, configuration is in the form of *.js files which are written in Javascript. In fact, code written using scripting languages tend to give little distinction between code and configuration.

The problem with compiled languages like Java is that we are biased and think of configuration as something entirely different from our code. In reality, it should be one and the same thing. The only real difference is that it is targeted to a different audience may require different permissions. So, maybe the next time you write a configuration file, maybe you should consider studying Java's security architecture.

Using Java class files for configuration may be too extreme a step. But, one can always leverage an existing java based scripting language to do the configuration for you. One would just need to devise ways to restrict capabilities of the scripting language. One example of this tactic is the use of velocity in the Roller blogging tool. Roller allows users to do scripting however within a controlled sandbox.

Configuration in its most general sense boils down to providing to a target audience a Turing Complete language in a controlled sandbox. The Rails framework eschewed configuration completely and as a consequence claims to have a more productive development environment.

So here's a piece of design advice, use a Turing Complete language for configuration. When you get to the point that you can clearly identify the audience of your configuration, only then should you consider mechanisms for controlling a users permissions. It's a waste of mental bandwidth to be trying to decide if something is code and something is configuration.

The design of your configuration should take into account usability. In other words, it should be designed just the way you design user interfaces. Just as a View's code is separate from the Model's code, Configuration should be separate from the core code. Separability in addition provides support for migration, something you will eventually need when you evolve your software.

In summary, distinguishing code from configuration tends to be fuzzy at best. There's really no real distinction between code and configuration, building one prematurely creates artificial barriers that compromises flexibility.