[ANNOUNCE] Config::Model - Framework for semantic validation of config data

[ANNOUNCE] Config::Model - Framework for semantic validation of config data

am 20.03.2006 16:07:25 von Dominique Dumont

Hello

I'm pleased to announce the first release of the Config::Model
(http://search.cpan.org/dist/config-model/) perl module.

The Config::Model provides a framework to help in validating the
semantic content of configuration data.

How does this work ?
--------------------

Using this project, a typical configuration validation tool will be
made of 3 parts :

1. The user interface
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

The important part is the validation engine.

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 compated to default values

What about the user interface ?
-------------------------------

Config::Model will also come with a Curses::UI interface that queries
the user's model and generate the relevant user screens.

Why an old-fashioned Curses interface ?
To be able to configure your system even if X is not running.

What about data storage ?
-------------------------

Since the syntax of configuration files vary wildly form one program
to another, most people who want to use this framework will have to
provide a dedicated parser/writer.

Nevertheless, this project can also provide a writer/parser for most
common format: like ini style file, or provide an interface to the
Elektra or debconf projects. 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.


The project homepage is located on sourceforge:
http://config-model.sourceforge.net/
http://sourceforge.net/projects/config-model/

Cheers

--
Dominique Dumont
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner