Config model design

dod38fr edited this page Feb 8, 2012 · 2 revisions


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


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.