Bridging the gap(s)
It seems to me that there are a few steps that are needed to get to a unified configuration file format:
1. Decide on the file format
2. Write bridges to let existing, unmodified applications work with the file format,
3. Convert the existing applications to use a standard API that may also use the new file format.
These steps can be broken down:
1a. Decide on a basic file structure.
1b. Decide on a set of common elements.
I would suggest simply using XML Schema and XML files to represent the configuration. It doesn't mean that XML files need to be used to store the config, just that the config can be serialized to/encoded from standard XML without losing information.
2a. Define a schema for each specific application. If necessary, extend XML Schema to include helper fields.
2b. Write bridging tools to convert between the XML format and the native format used by the target application. In the case of XML, you could just write XSLT transforms. These are much easier to keep up-to-date than straight code.
Part 2 means that we are not locked into a schema immediately -- we can play around with the schemas until we are happy that they provide all the functionality of the original files.
3a. Write a simple mechanism for accessing the configurations. XML gives us XPath and the DOM, which means that writing configuration parsers is straightforward -- we have ways to refer to any given node in a configuration file and we have a low level API for accessing it easily. So really a configuration file parser is simply a wrapper around the DOM.
3b. Write a configuration editor for each tool. With XML this is simple, you just need a tool that can read the XML schema definition -- IBM's Xeena tool (though written in Java) provides context-sensitive pallete for editing an XML document based on the DTD, so doing the same for an XML Schema should be fairly straightforward.
The advantages of this scheme are:
1. All the basic tools already exist as free software.
2. Potentially 100% compatability with old applications
3. Most of the code is XSLT and therefore more easily maintained than a hard-wired parser (I am only arguing that XSLT is easier to follow than C code implementing a parser for the same structure).
4. Permits graphical or text based configuration
5. In conjunction with the kernel file monitor and a simple daemon, modifying the XML source of a configuration file could automatically cause the daemon itself to restart (obviously this would need to be configurable, too).
6. Very easy project to start; there are not thousands of lines of code to write.
7. 100% standards based, most of this stuff developers are already familiar with (or should be).
IMO the approach of linuxconf, Ximian Setup tools and Webmin is all wrong wrong wrong. Unifying the configuration can be done without initially rewriting the applications. Start from the bottom -- unify the configuration first and let the application authors decide when, if ever, to jump on board.
Finally, the file format could permit references to "included" configuration files, the storage of which could be in multiple places including over the network. For example, the standard configuration document (e.g. /etc/xcf/bind.xml) could include configuration from http://server.example.com/xcf/slave.xml. This would optionally permit configuration to be based on a single server or alternatively across multiple files.