Re: [Setup-tool-hackers] Re: [Config4gnu-developer] Re: Re: CFGconfig management (/etc etc.)

[Carlos Garnacho <garnacho tuxerver net>]

Hi Justin!

sorry for the delay, I've been travelling and it's one of the first
times I could grab an internet connection :)

El mié, 12-11-2003 a las 23:08, Justin Yackoski escribió: 
> This is some great discussion, thanks to everyone for your thoughts on CFG.  I just want to clarify a few things regarding CFG's design (most, but not all, of the things I'll be mentioning are currently working)
> 
> On Mon, 10 Nov 2003 14:00:42 +0100 (CET)
> p.carsten@arcor.de wrote:
> 
> > 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.
> 
> We had looked at GST/Helix Setup Tools about a year ago, and decided to use a slightly different approach.  At the time it also appeared to not be in active development.  I think there's a lot of potential for collaboration between the two groups.  In fact, I think that GST could comfortably sit on top of CFG by developing a very nice GTK frontend and contributing/merging the rest with CFG's other layers.  Not that CFG is necessarily better, I'm just saying it would not be hard to do.

but OTOH, the first objective of the GST isn't to provide gnome
frontends, just an standard way to configure the system

> Anyway, CFG was intended to edit ANY configuration.  We initially focused on stuff in /etc for Samba, Apache, etc. because we were hoping to get the developers of those applications to help add support for them.  This was mainly because things like Gnome have more user-friendly (context-sensitive help, nice look, etc.) config tools than those apps, so we thought there would be more interest.  We were wrong, or we didn't get the word out properly. :) 
> 
> Its main intent is to create 3 layers with separate purposes
> 
> bottom: parsing various config formats into generic XML
> 
> middle: transforming generic XML into more specific XML, adding
>         extra information (documentation, defaults, rules, etc.)
>         all special XML elements are sub-classes of generic XML
> 
> top:    main UIs edit generic XML, and also know how to ask for
>         extra information (defaults, context-sensitive help, etc.)
> 
> I believe that GST splits some of our middle layer's functionality into the top & bottom layer.  I think a middle layer is important here so that both the bottom & top layers can be more generic, so that in most
> cases to get a new app supported by CFG, you just add support in the
> middle layer (via an XML meta-data document).
> 
> I'm sure there are advantages and disadvantages to this approach.
> 
> > > > 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)
> 
> CFG does think that most configuration is essentially key value pairs (lists & other things that can be represented in XML are supported too), but that doesn't mean the user edits key/value pairs ala the windows registry.  

that can be mostly applied too to the GST :)

> The bottom layer converts config data into XML key/value pairs, the middle layer says that a key for say GTK's config named "background color" stores a "color" type of value and validates that a rogue user/GUI doesn't try to set it to an IP address, and the top layer is responsible for rendering a nice color wheel widget to pick a color when it is told a particular key stores a color value.  
> 
> This allows the top layers to be very generic GUIs whose layout is modified by the XML meta-data files describing the keys, and forms & wizards to display them.  Last I checked, GST had somewhat hard-coded GUIs that looked for specific config data.  Is this still the case?

yes, it is, we think that this is more correct to fit into the several
GUI guidelines (read HIG, or whatever) or to show the more correct GUI
approach when using different possible GUI methods (GTK/QT, text mode,
web...)

> > 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?
> 
> I think so, but I bet someone from GST could explain this better.

a single backend is completely generic to all possible frontends, the
frontends only have to care about changing the xml and sending it back
to the 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)
> 
> This is exactly what our primary goal is.  You only add/change support in *1* place.  We felt that changing things in more than one place was a waste of work, and we wanted a tool that kept all the very specific meta-data in 1 place.
> 
> > 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?
> 
> Me either.  CFG doesn't make any attempt to change existing programs.  This is a fairly common misconception.  CFG is purely an abstraction layer that converts existing config data into an easier to work with standard XML format, and then converts it back again when you save your changes.  If we didn't tell you on our website, nothing would know that it did this or that it uses XML, but we mention it repeatedly because it is what makes CFG better in our eyes.
> 
> At the same time, CFG makes it possible to actually store the config data into XML.  We just skip the convert to/from XML step in this case and write it directly to someplace on the filesystem. 
> 
> CFGs organizational structure is merely what the GUIs display it as.  We thought grouping configurable things (apps, daemons, libraries like GTK, etc.) into more logical groups was best, so thats what we did.  
> 
> You can easily modify this by editing the data/config4gnu.xml file to make it whatever you like.  This file basically maps each thing in the heirarchy to the actual config files in /etc or whereever.  Currently, CFG uses the heirarchy defined in that file to locate configuration, but we want to make it possible to say "I want the config for the apache webserver instance #1" or similary, so users can rename & regroup things.
> 
> > > 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. 
> 
> Yes, CFG does this.  Is it true that GST needs a new front & back end?

if the feature added is just to add support for X to distro Y, then you
only need to change the backend, no changes to the frontend are needed,
but if you are adding a new functionality/configuration tool, then you
might want to write a new frontend

BTW, the frontends are designed to be as small as possible, the biggest
one has ~7000 code lines, and the smallest <1000, that's mostly a little
ammount of code that IMHO respects as much as possible the several GUI
guidelines

	regards 

> 
> Justin
> 
_______________________________________________
setup-tool-hackers maillist  -  setup-tool-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/setup-tool-hackers