Objectives and properties of config model

Table of Contents Config::Model objectives Help people configure their system Help developers to help people configure their system Config::Model properties

Config::Model objectives

Help people configure their system

In 2005, I've installed a Debian system for my mother in law. As a user, she is very happy about it. She can edit her mails, browse the internet like any other computer user. 6 years later, she has begun to install some package with Synaptic, but I'm still doing the administration. I handle the package updates and the configuration. Why is that ? Because these tasks are not easy.

Configuring an application like sshd is too difficult for her. To correctly update a configuration file, she would have to:

• Edit a text file outside of her beloved /home
• Read man pages (which are often too detailed)
• Read the logs to fix mistakes she mades

So here's the first objective of Config::Model project:

• Provide a configuration GUI
  • with integrated help
  • which hides complex details from beginners
  • detects errors as soon as possible

Configuration can be even more difficult during package upgrades. With her Debian system, she can be asked intimidating questions, like if she wants to keep her file, accept the maintainers version, or view a diff (a what?). RedHat user situation is not brighter as either user data or package data may be left in rpmsave or rpmnew files. RedHat user may have to perform merge manually afterward.

So, here's another objective of Config::Model project:

• Upgrade configuration without questions

Some GUI for configuration tools are provided, like cups web interface, vdr admin, wedmin, Kde system-configuration. Unfortunately, they often have a different look and feel, which can confuse her.

Let's add another objective:

• Upgrade configuration without questions

Of course, not all users are like my mother-in-law. Some users will prefer to update their configuration files with their favorite editor. On a same system, we may have people with different background who will prefer different ways to achieve the same task. In this case, Config::Model must not get in the way.

So here's another very important objective:

• Allow manual edition of configuration files

Help developers to help people configure their system

I'm pretty sure I'm not the first wanting to improve configuration tools. There are other projects like Webmin or Elektra. To write configuration GUI, developers must create:

• The GUI
• The parser and writer for the configuration file
• The validation logic
• Specific code to handle configuration upgrade when the application evolves

You may need to repeat this process for each application...

If all these features are implemented with dedicated code for each application, maintenance and evolutions can become a huge task.

So, here are the objective targeted for developers:

• Minimize the extra development work
  • No dedicated code for GUI
  • Re-use of parser/writer code
  • Minimize work to provide validation logic
  • Minimize work to provide upgrade logic
  • Minimize maintenance work

Config::Model properties

Now, let's have a look at the list of objectives (re-ordered so the explanations will be easier to follow):

1. Allow manual edition of configuration files: All data is stored in the regular configuration file. There's no separate registry of configuration data. Comments should be preserved.
2. Minimize work to provide validation logic and Minimize maintenance work: Instead of requiring hard-to-maintain validation code, validation is based on a formal description of the structure and constrains of the configuration data: the configuration model (more on this later). For those familiar with XML, you can view this as a XML schema on steroïds.
3. Upgrade configuration without questions and Minimize work to provide upgrade logic: The model can feature deprecated configuration parameters. Similarly, new parameter can be introduced and have their values migrated from deprecated parameters.
4. Provide consistent user interfaces and No dedicated code for GUI: GUI are generated from the model
5. Re-use of parser/writer code: Parser/writer (AKA backend in Config::Model doc) are used by models (but not part of them)
6. GUI with integrated help : Models feature summary, description and other help text which is used to generate the help text in user interface
7. GUI hides complex details from beginners: Parameters in models can be tagged with an expertise level. This expertise level is used by the GUI to show or hide parameters.
8. detects errors as soon as possible: Config::Model use the model to check user value as soon as they are entered in the GUI