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

[Alex Hall]

Paul Gearon wrote:
> On Wed, Jun 3, 2009 at 2:22 PM, Alex Hall<alexhall at revelytix.com> wrote:
[snip]
>> 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.

As are all of the options for fine-tuning the Jetty connectors.  It
would be impractical to try and add command-line switches for all of
these options.

> 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?

Sounds great -- I was thinking along those same lines.  No user should
have to maintain a complete copy of the same mulgara-config.xml that
gets compiled into the source configuration.  Making all the elements
optional would take care of that issue; we would just need to be sure
that the config used at compile-time actually contains all the necessary
elements.

Merging two copies of the config structure seems like a reasonable
approach.  The one difficulty that I see here is that this approach only
lets you add new components or override existing ones.  It would not
cover the case where, for instance, the user wishes to disable one of
the resolvers.

Regards,
Alex