Scope of project
while I have to agree that standard configuration is needed in linux, I think that the scope of the project is too broad. IMHO a much better approach is to attempt to create a standard set of tools (library) that handles parameters and values indexed by key. While there are certainly complex configuration formats in applications, I believe that they are the exception rather than the rule.
If a sufficient library were created that offered 80-90% of the needs of programmers it would simplify the configuration of all of those applications that don't require advanced configuration formats. I also believe that a simple key, parameter, value format can be adapted to more advanced files albiet with a little work. This should be the job of the application to handle the various complexities that arise such as parameter contexts and overrides, etc.
The simpler the better. I believe that once a good toolset is in place people will want to use it. Key, parameter, values models data structures accurately. A key item that offers flexibility is the muli-valued parameter using a delimiter. Quoted strings should be used to enable delimiters to be used in a config:
[ KEY ]
param1 = something, "something else, blah,blah", another
Hierarchies can be created using dot notation:
param1 = something
param2 = something, "something else, something else,", one more thing
[ Some local key ]
param1 = foo
param2 = bar
param3 = baz
[ Some local key.overrides ]
param1 = something different
Etc. So contexts are created using dot notation rather than braces. Each level in the heirarchy that is associated with a given key is up to the application to handle. After all the config file should just store parameters and values. If we need to handle default values, we can add another section:
[ Some key.defaults ]
param1 = default foo
param2 = default bar
param3 = default baz
Comments can be stored easily and associated with either some key or parameter. This way the documentation is in the config file. If for instance a GUI were to be made, it can simply pull the comments out of the config file and display them.
For similar generic items you can create a key that using numeric increments like for modelines in a xconfig file.
[ Modelines ]
total modes = 4
The toolset should not need to be aware of this situation, the application should interpret each modeline by
I just don't think the problem requires massive amounts of engineering. This solution is simple, it works and can be adapted. If we find out for some reason that a particular requires some complex format that can't be adapted (I refuse to believe that with enough creativity a config format can't be adapted somehow), then extend the format in an intuitive way to allow more advanced configuration. This way you can get 80-90% coverage for the simple config files and still allow advanced functionality using the same library.
I believe that this is the key to a uniform config system. Once everyone is using the same library, then you can create a generic framework to localize configuration of all these various config files by extending the toolset to include a simple registration system allowing a single app to version configurations, save, backup, alter, use ACL's etc. But the first step is to "market" this flexible toolset to developers.
Start small, why spend massive amounts of time engineering something when this solution is so trivially simple it's possible in such a shorter time frame. Once this phase is accomplished, you can create another toolset (library) that will parse the config files and build a GUI automatically by reading all keys, creating the menu hierarchy from the dot notation, reading all parameters and putthing them into a GUI list control, extracting the comments, and anything with a *.default can be plugged in. Heck you could even create an *.option if you needed in order to dynamically generate all of the possible values for a specific parameter. This can all be done in various languages with ease. A C API could be created, a set of simple C++ classes, perl modules, python modules. Porting something like this is far easier than some 3 tier system with XML and all that jazz.
I personally would rather spend my time on something like this rather than some massive engineering effort to try to unify already existing config files. This is just much simpler than a 3 tier approach. Just my $1.50 here :)