well-designed configuration library

Current status

The project is in its initial phase. Currently requirements capture and analysis are being done.

You're invited to participate

1. As a future user of wd-config you can:
   1. express your vision of what a good configuration library should provide to a programmer:
      1. what
   2. share your experience of using similar libraries, for example for command line parsing, reading configuration files, object serialization, etc.:
      1. what is your general impression of that library?
      2. what features were particularly useful for you?
      3. what could be done better?
      4. what functionality was lacking for your needs?
2. System architects are also invited to work on design of the configuration library.

Contact information

When you have questions or suggestions and if you would like to contribute, send you message to the wd-config-devel mailing list.

wd-config is maintained by Alexander Konovalenko. He can be contacted directly by the email AlexanderKonovalenko AT yahoo DOT com.

Development

This is what have been planned by now. More items are to come.

Proposed features (functional requirements)

1. Various types of configuration sources:
   1. parsing command line options,
   2. environment variables,
   3. reading configuration files:
      1. hierarchically organized multiple config. files,
      2. various file formats.
2. GUI for editing preferences.
3. Asynchronous reconfiguration in run time.
4. Maintainability of complex configuration processing:
   1. semantics, syntax and documentation of a config. option are stored in a single place [FIXME: inaccurate].
5. Flexible error handling:
   1. no error checking,
   2. validation without determining the exact cause of an error,
   3. automatic generation of user-friendly error messages.
6. Support for delegating parts of configuration to other modules.

Non-functional requirements

This is a list of non-functional requirements to the library.

1. Simplicity:
   1. fast [FIXME: wording] learning curve,
   2. amount of required library knowledge and complexity of code that uses it is proportional to the complexity of the task [FIXME: more concise wording].
   3. [FIXME: for some strange reason it isn't simple for me to express the simplicity requirements :-) ]
2. Extensibility:
   1. new config. file formats can be added,
   2. new configuration management schemes can be added.
3. Universality.
4. Standard-compliance:
   1. the library will take advantage of the full feature set of the ISO C++ standard (ISO/IEC 14882:1998).
5. Efficiency:
   1. speed of execution is close to non-general code that does the same,
   2. no speed overhead caused by unused features,
   3. no size overhead caused by unused features.
6. Portability.

Development process requirements

These requirements will serve as guidelines for wd-config developers. The users of the library will be influenced by them indirectly.

1. More or less rational [FIXME: add an explanation or change the wording] process:
   1. use-case driven,
   2. architecture-centered,
   3. iterative and incremental.
2. Maintainable library code:
   1. readable,
   2. well-commented,
   3. consistent and idiomatic,
   4. easy to debug,
   5. simple to test.

Related projects

AutoOpts

Powerful command line option parser for C.

See also wd-config's Savannah page (not very useful for now).