Config::Model provides a framework to help in validating the semantic content of configuration data.
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
What's New in This Release: [ read full changelog ]
· The main change of this release is to provide asynchronous store check.
· Now, a model can check the validity of a configuration value against a remote resource in a non-blocking way.
· This is currently used by the Dpkg model to check the validity of package names with the Debian server through several concurrent HTTP requests.
· The Debian Dpkg model has been moved into a Debian native project.