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

[p.carsten at arcor.de]

On 11/13/2003 10:02 Carlos Garnacho wrote:
 
> 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

A very good idea, and they probably have inspired CFG a great deal. Now CFG offers a way to even trivialize creating support for new things to configure in all frontends simultaniously. The idea can also be true for any application/service you want to use.


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

This is ok as long as a frontend reimplementation is only needed in order to get a native app for a particular GUI/text library, or if you want to follow other HID guidelines with your frontend. The middlelayer stays the same for all frontends.

Reimplementing and maintaining every configuration feature in each frontend is however very inefficient.

> > To support a new application distribution independent in all [CFG] frontends
> only its meta-configuration datails 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? 

CFG and its frondends do not have or need a special "boot-conf" or other functions. It can simply configure all files it has a meta-config-description for. 
In general there is only one "bootloader" package grub or lilo installed, together with it it's meta-config. So CFG middlelayer finds it and a new configuration node is added to the xml-tree.

IMHO there are sometimes mismatches between the functionality of
> some similar tools that may need hardcoding... :)

This is only true from the standpoint that all different but simillar tools should be configured by the same and "easy looking" hardcoded functional oriented GUIs.

But how easy it can be to configure a package is defined by the package itself.
A package or configration file oriented system like CFG can provide the easiest (even multiple) way to configure a file with the meta-configuration-data. Lilo and grub will differ in their capabilities so will probabliy their configurations, it might still be possible to have the wizards defined in their meta-configrations ask the same questions.


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

If GST, other frondends and even the applications themselfes use CFG as its "backend", thousends of new lines of code would only be neccessary to make the whole system configuration available under new UI-Guidelines or other toolkits. And not each time someone wants to have a new function in his particular Frontend. Not talking of the ongoing need for maintanance of hardcoded frontends due to changes in the packages configuration or handling of different versions.

Kind regards,
Peter