| Table of Contents |
|---|
Goals
- Identify the options that are most commonly changed and hardwire the rest.
- Provide defaults without explicitly showing them to limit size of file(s).
- Identify the configuration scenarios that address 80% or more of use cases.
- Avoid the need to use XML for the most common scenarios.
- Provide constrained options that encourage recommended approaches to deployment.
- Allow straightforward migration from "simple" to "standard" configuration.
...
Most of this material should be hardwired with a few defaulted settings exposed.
Probably will want to include new algorithm blacklist/whitelist feature (shouldn't have to compromise long term security for simpler format).
Implementation Notes
Windows INI format is probably the logical choice for the core config, though it makes repetition of property sets and inheritance very ugly. Probably need to forget any sort of inheritance at all.
The various plugins require DOM fragments to supply properties during construction, so the implementation will need to construct these fragments. If it's really possible to turn "simple" into "standard", the most sensible thing to do is just generate the "standard" XML and load that using the existing code.
This leads into the problem of how to specify the configuration style in use, and support the competing goals of using the simple form by default in new releases, but supporting the standard form after an upgrade with no special additions. The configuration pluggability layer has features designed to allow alternative implementations, but those features would require setting environment variables or using special commands and options. So the fallback position would be to stick with the default plugin type of "XML" and just auto-detect the format from inside that plugin.