Config::Model provides a framework to help in validating the semantic content of configuration data.
Version: 0.639Config::Model provides a framework to help in validating the semantic content of configuration data.
Operating System: Linux
Config::Model can also be used to provide a semantic check of options of a complex program like mplayer or transcode.
How does this work ?
Using this project, a typical configuration validation tool will be made of 3 parts :
- The user interface
- The validation engine which is in charge of validating all the configuration information provided by the user.
- The storage facility that store the configuration information
Don't we already have some configuration validation tools ?
You're probably thinking of tools like webmin. Yes, these tools exist and work fine, but they have their set of drawbacks.
Usually, the validation of configuration data is done with a script which performs semantic validation and often ends up being quite complex (e.g. 2500 lines for Debian's xserver-xorg.config script which handles xorg.conf file).
In most cases, the configuration model is expressed in instructions (whatever programming language is used) and interspersed with a lot of processing to handle the actual configuration data.
What's the advantage of this project ?
The Config::Model projects provide a way to get a validation engine where the configuration model is completely separated from the actual processing instruction.
The configuration model is expressed in a declarative form (i.e. 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 (boundaries, check, integer or string, enum like type ...)
ï¿½ the default values of parameters (if any)
ï¿½ mandatory parameters
ï¿½ the targeted audience (intermediate, advance, master)
ï¿½ on-line help (for ach 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
ï¿½ upgrade of configuration data is easier and sanity check is performed
ï¿½ audit of configuration is possible to check what was modified by the user compat