[Mulgara-dev] A better approach to config files?

[Paul Gearon]

On Wed, Jun 3, 2009 at 2:22 PM, Alex Hall<alexhall at revelytix.com> wrote:
> I'm in the midst of upgrading a Mulgara installation on a production
> system from 2.0.x to 2.1.1, and the process is making me painfully aware
> of how awkward it can be to work with the mulgara-config.xml file.
> There are two general complaints I have with the current approach:
>
> 1. Config files are required to comply with the mulgara-embedded.xsd
> schema.  If the schema changed from one version to the next, Mulgara
> will refuse to start with my old config file until I go find the new
> schema, figure out what changed, and update my config file.
>
> 2. The contents of a config file entirely replace any built-in defaults
> rather than add to them.  For instance, Mulgara 2.1 adds a new RLog
> content handler to the default configuration.  Since I'm running with an
> external config file that predates RLog, I can't use RLog until I go
> manually add it to my configuration.

Yeah, that'd be annoying.

> To some extent, this is a philosophical question.  Should a config file
> contain a complete system specification, or should it contain selected
> overrides to a default system configuration?  If the config file
> completely specifies system behavior, then you have to find and copy an
> existing config file (none is currently shipped with the binary
> distribution) and update it with each new version.  I think that the
> selective override approach is more in line with what most users expect
> to see, and will give much better results in the face of the inevitable
> changes to available configuration options that are introduced between
> versions.
>
> Any thoughts?  I know that replacing the existing XML-based
> configuration probably isn't feasible at this point, but I wanted to at
> least open the topic for debate.

In one sense, the XML file provides the "built in" definition of the
defaults for Mulgara. To override those defaults you use a set of
command line switches and system properties. The configuration file
doesn't need to be updated except by someone who a) knows what they're
doing, and b) is trying to change the config permanently.

However, that's not the whole story.

First, there are settings that can only be modified in this file. RLog
is an example.

Secondly (and more importantly) there is also the case of the
user-supplied configuration. Implicit in this option is the need for
users to adjust their configuration. But I really like your suggestion
that this file might contain values to override the defaults. In that
way we could keep the built-in defaults (in a rarely accessed XML
file), and allow users to easily override these values with a
user-provided XML file.

The main problem is that we're using Castor for this, and I don't know
how well that library would work in this case. But it might just be a
case of making everything optional, and we'd be fine. So then we'd
need some code to read the defaults into the config structure, and
then override them with anything found in a user-provided file.

How does that sound?

Regards,
Paul Gearon