
Config::Model - Describe and edit configuration data

Config::Model provides a framework to:
- describe the structure and constraint of your configuration
- edit and check you configuration data.

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

Using this project, a typical configuration editor 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. This engine is
      made of the framework provided by this module and the
      configuration description.
   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 (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 (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 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.
- beginners 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 compared to default values

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

Config::Model comes with a shell-like interface.

Config::Model::CursesUI provides a curses 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.

If time permits, I may write a perl/Tk interface. Help is welcome on
this topic (or help with any other toolkit)

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.

Is there an example of a configuration model ?
----------------------------------------------

The "example" directory contains a configuration model example for the
/etc/fstab file. This example includes a small program that use this
model to show some ways to extract configuration informations.

What is the status of the project ?
-----------------------------------

- Most of the model handling code is Beta 
- Terminal interface (TermUI.pm) is alpha
- Curses interface (provided by Config::Model::CursesUI) is alpha
- Xorg model (provided by Config::Model::Xorg) is alpha

Help is welcome on:
- graphical user interface (gtk or perlTk)
- backend storage (use Config::General or ldap maybe ?)
- configuration model creation (if you have a configuration itch to
  scratch, you're welcome)

If you want to help ?
---------------------

Send me a mail at: ddumont at cpan dot org.

Is there more documentation ?
-----------------------------

Yes, on sourceforge:
  http://sourceforge.net/projects/config-model

What's the licence ?
------------------

    Copyright (c) 2005-2007 Dominique Dumont.

    This file is part of Config-Model.

    Config-Model is free software; you can redistribute it and/or
    modify it under the terms of the GNU Lesser Public License as
    published by the Free Software Foundation; either version 2.1 of
    the License, or (at your option) any later version.

    Config-Model is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
    Lesser Public License for more details.

    You should have received a copy of the GNU Lesser Public License
    along with Config-Model; if not, write to the Free Software
    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
    02110-1301 USA

---------------------------------------------------------------------
INSTALLATION

   	 tar zxvf <dist_file>.tar.gz 
   	 cd <dist_directory>
   	 perl Makefile.PL
   	 make test          

If you want to install this software without packaging, type also:

   	 make install
