CFG config management (/etc etc.)

[p.carsten at arcor.de]

Hello everyone, 
 
and thank you very much to the people who commented on CFG. 
 
Carlos Perelló Marín wrote: 
> > This is a proposal for a config file handling framework. 
> > Config4gnu or CFG for short is unlike the config "tools" existing 
> > today. 
> 
> It's something like the GNOME System Tools' backends 
 
Oh, indeed. I am sorry, I did not know about them before. Thanks for pointing them out. 
Reading your website it looks like CFG and GST have a lot of common ideas, and that GST has allready come a long way in making really nice frontends and grafics 
 
As I understand the Gnome tools also use abstracted XML Data to communicate with their current backends. 
The difference seems to me that GST have started from the need of a System Tool for GNOME (well that is actually the name ;-) ) whereas CFG was inspired to have a nice framework for flexible and simplified handling of any /etc configuration, systemwide. 
 
 
> > In the future these definiton files can be maintained within 
> > the different software packages so that its central configuration is 
> > instantly availabe upon installation. 
> 
> I don't see the beneficies for that kind of "rendering" the settings, 
> it's just like a normal edit but it does not hide the complex tasks, you 
> only have key/value entries with some extra information 
 
Yes just having keys and values is not really user friendly, that is why CFG is not limited to them and has also wizards and forms, however the keys and values are interesting for the applications themself if they want to read their configuration through the config4gnu (allready validated and with defaults) 
 
> lets you add any backend easily but what will you win with that? web 
> browser GUI? 
 
 
Am I correct that in order to configure a new thing with GST one would need to write a new module. (i.e a Gnome Frontend and a Backend) And other Interfaces (KDE, XFCE, etc.) would also need new modules? 
 
The approach in CFG is to have the configuration logic be within a middlelayer, so every Frontend that queries CFG can configure anything the middlelayer has a definition file for. 
All applications weather they are GUI-, text-, scipt- or API-based can make use of the same configuration wizards, forms, related documentation and help for a service without nessecarily knowing anything about the service itself. 
 
Another nice thing is, that nothing in the middlelayer or the backends is hardcoded to configure just a particular programm. 
 
To support a new application distribution independent in all frontends only its meta-configuration datais needed. (syntax, options, defaults and logic in the form of an xml file) 
 
 
Here I have copied some notes from Damien Uern who was also looking into GST and CFG. Trying to benefit both he writes: 
 
---------- 
> [GST] don't address the problem of 
> simplifying the /etc tree even for the user using vi to change their 
> configuration. Providing a fast, small, library that applications can include 
> to resolve the path to their config files is a good step to improving the 
> /etc file tree because then distributors can clean it up without breaking 
> apps or having to hack the code to those apps. 
> 
> The problem with CFG is that it wants to change every program that sticks a 
> file in the /etc directory. But IMO, this is a good thing, and I believe all 
> the Unix/GNU tools need to move towards a more structured, more logical 
> configuration system and have less reliance on hard coding paths at 
> compile-time (this goes for hard coding locations of data directories as 
> well!). 
 
I do not understand, how would CFG try to change the programs? 
 
> CFG also has the right idea in trying to get developers to include CFG XML 
> files in their program distribution so that, on installation, it is instantly 
> supported by the GUI tools, even though the GUI tools haven't been 
> specifically programmed for it. It seems that with GST, they have to 
> explicitly add support for everything at the frontend and the backend. 
> 
----------- 
 
 
Have a good day! 
-Peter 
 
 
 
 
> 
> > 
> > So far CFG provides a unified configuration API for all kinds of 
> > config files on a single machine. Frontends for WWW, GTK, comand line 
> > (scripts) or programms using the config4gnu API directly all see the 
> > same "configuration tree". Config4Gnu provides logic/consistency 
> > checking, activation of changes, "configuration wizards" and more. But 
> > at all times only the config files under /etc are authoritative and 
> > are still fully hand editable including the comments. 
> 
> Just like GNOME System Tools' backend :-P 
> 
> > 
> > The CFG parsers (backends) understand the syntax based on the 
> > config-file definition and dynamicly generate a xml representation of 
> > it. If a logic-definition is also available the middlelayer knows wich 
> > settings are common with other packages, which help texts are 
> > relevant, how to activate changes, etc. and about wizard and test 
> > logics. 
> > 
> > 
> > CFG is not limiting the personal choice of configuration file style 
> > for a programer, yet he has all the fancy stuff at hands easily. He 
> > could even use the Config4Gnu system directliy to parse and generate 
> > the configuration files for his application. 
> > 
> > According to the two main developers the system is fully functional 
> > and can edit many config formats. It supports samba nearly fully. But 
> > it is not ready for public use yet. For example some dependencies need 
> > to be cleared. 
> > 
> > Before the project started last year there had been an introductory 
> > article and discussion about it on freshmeat. 
> > http://freshmeat.net/articles/view/565/ 
> > 
> > To find out more about CFG visit 
> > http://config4gnu.sourceforge.net and look into our mailachives. 
> > Unlike the website states there has also been a tarball released.