Config model design

Design

The following diagrams shows a high level views of Config::Model architecture. The different colors highlight the provider of the different parts:

• In gold: provided by Config::Model developers
• In blue: provided by a developer
• In green: provided by end user

Description

A configuration tool based on Config::Model will be made of 3 parts :

1. The user interface (config-edit program)
2. The validation engine which is in charge of validating all the configuration information provided by the user.
3. The storage facility that store the configuration information

A configuration model is expressed in a declarative form (currently a Perl data structure) which is always easier to maintain than a lot of code .
The declaration specifies:

• the structure of the configuration data (which can be queried by generic user interfaces)
• the properties of each element (boundary check, integer or string, enum like type ...)
• the default values of parameters (if any)
• mandatory parameters
• the targeted audience (intermediate, advanced, master)
• on-line help (for each parameter or value of parameter)
• the level of expertise of each parameter (to hide expert parameters from newbie eyes)

So, in the end:

• maintenance and evolution of the configuration content is easier
• user will see a common interface for all programs using this project.
• user will not see advanced parameters which miht confuse them
• upgrade of configuration data is easier and sanity check is performed
• audit of configuration is possible to check what was modified by the user compared to default values

Configuration file reader and writer

There are a lot of different syntax for configuration files. Some are rather common like INI syntax, or XML. This project provides a reader/writer for some of these common formats. If your project does not use one of these format, you will have to provide a dedicated parser/writer.
Other reader/writer for rather common syntax can be integrated in this project. This point is open for discussion.
It is entirely possible for a single configuration model to use several parsers and writers so one model will ensure the consistency of several configuration files together.