PLEASE! READ THIS BEFORE POSTING
As one of the developers of the project, I'd like to clarify a few things that, judging by the comments so far, some people still seem to be grossly misunderstanding what our project is.
First off, our system is in an alpha stage at this point and we have proof-of-concept applications working very well with it, you should check them out at http://config4gnu.sf.net (http://config4gnu.sf.net)to get a better idea of what we've got.
Now to clear up some misconceptions:
Our system is an abstraction layer, *just like other config tools*. It is not a replacement for native config files, it does not require apps to use it, and it certainly does not intend to force a single way of doing things. It is just a tool that people can use to edit existing, plain text files one day, and the next day to edit them by hand if you wish. The system will provide an XML-based cache of configuration which you can use for various purposes. This XML cache will be kept up to date with the native config files, and NOT the other way aound. The beauty of our system is that you get an XML-based, structured interface to the native config files. Its just an interface, not necessarily a replacement.
Our system currently allows application developers to read their configuration easily using our API, though it does not require it. It is not a registry, it is an interface. If you want to write your own parser or your own file format, go ahead. We'll try to handle your special formats, but we'd like to keep the number of config file formats to a minimum if possible.
We intend the system to be for people who more or less know what they're doing. Someone made a good point that even if you have been a sysadmin for 20 years, there are just some apps that you don't configure often enough to remember all the details needed to hand edit a config file without consulting a fair amount of documentation.
Of course there are reasons why someone who doesn't know squat about unix should not be able to configure an important server in a production environment. Thats up to the boss. If they want to depend on someone being able to use our tool for their business to stay alive, they've got bigger problems.
*More importantly*, what if someone wants to mess with configuration on a *testing* machine? Why should it be so hard for them to learn?
Finally, here is a working example of how you could edit your Samba configuration with a perl script:
my $samba = config4gnu::get_configuration_root->resolve_path("/Daemons/Samba Configuration");
my $global_section = $samba->resolve_path(".samba-global");
my $wins_setting = $global_section->resolve_path(".wins_server");
print "Your samba's wins server is " . $wins_setting->get_string_value;
This example script asks the config4gnu library to load the samba configuration file (i.e., /etc/samba/smb.conf) into XML, locate specific nodes in it, and retrieve the output. Modifying it is just as easy, and the change is saved back in the native config file without changing ANYTHING else (whitespace, comments, blank lines, etc.).
The actual XML data is organized by nested <section> tags, which accomplishes the necessary grouping. The individual parameter/value pairs are inside one or more levels of <section> tags. Currently, we don't have a parser for apache style config files, but this would be a goal. Even with INI style files (like samba), the same issues rear their head. For example the guest ok directive can be used to globally allow guest access to samba shares, and any sections inherit this default value unless it is explicitly over-ridden. From my experience, apache works in the same way (more or less).
At the very least, we will need to provide a way for the system to be aware of default values, which will be inherited by all sections including the highest or global section. If carefully written, this inheritance could easily be extended & handled as the XML is processed (either to or from the top-level) by the middle layer. It is going to be a tough problem to tackle, but as you mentioned, I think the nature of XML will help make it easier. Properly handling defaults & inheritance will be very important for the project's success since otherwise it won't be very useful for a lot of situations.
As far as using only diffs of the new and current config files, we can currently completely reconstruct the config file *exactly* (byte for byte identical) as it was from our XML representation of the data. If we can do this, and we checked to make sure the file hadn't been changed by one user as another was editing it by hand, we should be ok. Either way, since we can re-create the exact (or slightly modified) config file, producing a diff of the two wouldn't be difficult either, and may be a good option (among others) for logging. Thanks for your input!