Re: [Setup-tool-hackers] Re: Re: CFG config management (/etc etc.)

[Carlos Garnacho <garnacho tuxerver net>]

Hi peter!,

El lun, 10-11-2003 a las 14:00, p.carsten@arcor.de escribió:
> 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.

not exactly, the GST started from the need of adding a common background
for all the system configuration issues, they have been called GNOME
System Tools pretty recently, before this they were called Ximian setup
tools and IIRC Helix setup tools.

the idea that the HST/XST/GST wanted to inspire is that creating
frontends for a single backends should be a "trivial" task, keeping them
only a few thousand lines long, and I think that this is true for any
graphical/text library you want to use

> 
> 
> > > 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 frontends should be written for every GUI/text library, the backend
would be common for all frontends, for example, there is knetworkconf,
which uses the network-conf backend

> 
> 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)

:-? but it is sometime neccesary, for example, the boot-conf backend is
able right now to configure grub and lilo, but there's a (at least
little) need of hardcoding some issues. could you explain me this more
deeply? IMHO there are sometimes mismatches between the functionality of
some similar tools that may need hardcoding... :)

anyways, the GST backends are flexible enough for adding easily more
support for other programs and configuration files

	regards


> 
> 
> 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.
> 
> 
> 
> 
> 
> _______________________________________________
> setup-tool-hackers maillist  -  setup-tool-hackers@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/setup-tool-hackers
> 
_______________________________________________
setup-tool-hackers maillist  -  setup-tool-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/setup-tool-hackers