The purpose of this document is to explain in detail how various
parts of the system will be implemented. It is intended for those
interested in understanding and/or contributing to the CFG codebase,
or those who want to make use of some or all of the CFG system.
Some very specific and very abstract details are available in the
API Reference and the Schematic Diagram, respectively.
This document will contain many ideas which previously existed only
in the developer's heads, or perhaps scattered amongst comments in
code. Due to its nature every effort will be
made to keep this document up-to-date with our currently
implementated features as well as any plans for new ones.
This document is not intended to be 100% sane and complete all of
the time. It is more important that it stay up to date as much as
possible than have complete but incorrect information. Some
sections' implementations are still partly or wholly undetermined,
others may not even be included in this information yet.
If you want to comment on this document, please do so via the
mailing list. If you have a large change you'd like to suggest we
make (or we've said we liked your comments and asked you to submit
changes to this document), you can send a patch of the source
version of this document to the mailing list. The DocBook XML
source is available via CVS as
/website/docs/implementation/implementation.xml.
In order for maximum clarity in communication of our
implementation, it is important to define certain terms used in
this document.
Native Configuration File
A native configuration file is a file as
stored on a traditional Unix setup and read by a Unix
application to store configuration. Native configuration files
vary widely in format from one application to the next, and
even from one distribution of Linux to another. The
Config4GNU project will maintain existing native configuration
file formats, in order to remain compatible to other
configuration software and to allow coverage of legacy
applications without changes.