There have been many "flame wars" over the merits and demerits of centralized configuration storage schemes.
Lumping configuration data, security data, kernel tuning parameters, etc. into one monstrous fragile binary data structure is really dumb. | ||
| -- David Skoll | ||
Unix subsystems that use the Unix Philosophy principle that you must Store numerical (and other) data in flat ASCII files are not vulnerable to the mass destruction possible with the Windows Registry. Having separate configuration in separate files has the joint merits that:
By having configuration data reside in completely separate files, applications will not accidentally update entries that they shouldn't;
More often than not, most of the configuration data
generally only gets read. Daemon configuration
that only gets accessed by read()ing the file
has no vulnerability to overwriting
information;
By having data in separate files, independently accessed, there's not vulnerability to a single bad file write destroying the integrity of the whole "database".
There are nonetheless some strategies available to provide consolidated views to allow the diverse sets of system configuration to be looked at using some common formats and utilities.
The merit to using these common libraries/schemes is threefold:
Avoids the need to gratuitously recreate configuration data parsers;
Provides code that is well-debugged, providing robust handling of things like file locks;
May support providing metadata that allows multiple configuration files to be joined into a virtual "registry" that can allow the creation of a "configuration explorer" that might integrate into the tools described in Linux System Configuration Tools. ( libPropList seems to particularly contemplate this...)
If multiple system components use the same configuration "library," this makes it easier to create a common tool to configure the various system components.
The libPropList library, hereafter referred to as PL, uses an
opaque data type to represent a tree structure made of strings, data
blocks, arrays and dictionaries (key-value pair lists). This structure
can be manipulated, written out to and read in from a file, and
synchronized with the contents of a file. The purpose of PL is to
closely mimick the behaviour of the property lists used in
GNUstep
and OPENSTEP (there formed with the
NSString, NSData,
NSArray and NSDictionary
classes) and to be compatible with it. PL enables programs that use
configuration or preference files to make these compatible with
GNUstep or
OPENSTEP's user defaults handling
mechanism, without needing to use Objective-C or
GNUstep or OPENSTEP themselves.
This package contains libraries and header files for developing programs which use libPropList.
Note that it is now used with some GNOME programs such as the mail client, Balsa.
LIBconf is intended as a general-purpose NDBM-like interface into a text file, although the dbm base has been augmented a bit by used and unused keywords, and much better diagnostics (and decremented by not having functions to set values for a key or remove individual keys).
This Ada package is intended to be a platform independent and easy to use API to access configuration information. Under windows the configuration is stored in the registry, under Unix as configuration files. Also it should be easy to add other storage pools for configuration informations, for example ldap or a database .
GConf is a configuration database system, functionally similar to the Windows registry but lots better! It's being written for the GNOME desktop but does not require GNOME; configure should notice if GNOME is not installed and compile the basic GConf library anyway.
GConf does require glib, ORBit, libxml, and the popt option parsing library. It will optionally build Guile wrappers as well, if you have Guile. XML will be optional in the future if someone writes another storage backend.
Multiplexed configuration data access proposal for Debian
People trying to come up with some common way of configuring various Linux facilities could do a lot worse than consider an IETF RFC that seeks to provide a protocol for this purpose... See also ACAP RFC text - Application Configuration Access Protocol (RFC 2244)