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

[Alex Hall]

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.

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.

Regards,
Alex