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

[Justin Yackoski]

On Wed, 19 Nov 2003 09:57:56 -0500
Carlos Garnacho <garnacho at tuxerver.net> wrote:

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

I think that what you guys have done is great, and hate to see duplicate effort.  So lately I've been thinking about the differences between CFG and GST to try to figure out what we have in common and how we might be able to join forces.

Unfortunately, it seems that the only thing we could potentially share is that CFG's parsers could probably be used by GST, but the XML from the GST frontends would first have to go through an intermediary that was a lot smarter than CFG's parsers.

I think the major design difference is that CFG has a large middle layer (which uses the XML meta-data) and very dumb bottom and top layers.  Instead of a shared middle layer, GST puts all the meta-data about configuration into either the backend or frontend.  This makes the two systems rather incompatible because our backends are too simple for your frontends, and your backends wouldn't be usable by us because our frontends are too simple to work without additional meta-data.  

IMHO, sharing a single backend among frontends as GST does is a step forward from existing config tools, but having a smart middle layer and pretty dumb front and back ends is an even better approach.  It makes everything much more modular, and if the middle layer is fully driven by XML files, then changing/adding its support is MUCH simpler, and various other apps can add or update their XML meta-data files during their installs, so the actual config tool doesn't need to be recompiled or updated most of the time.

I think that if GST didn't feel a need for smart frontends, you'd probably move toward a middle layer of some sort and make the backends be a little dumber as well.  

It seems GST's reservation for not having very generic frontends is that some things appear to need hardcoding to make them HIG compliant and easy to use.  After working with CFG for a year, I am very confident that this is quite simply not the case.  We've had many people criticize CFG for this exact reason, but we haven't yet come across a special case with either the backend's data parsing or the frontend's data display that could not be handled by additional XML meta-data and some minor changes to the middle layer to use that additional meta-data.

I'm very curious as to what special cases you've come across that were hard/impossible to handle more generically.  I'm also curious as to why GST decided that it was better to treat every type of special case (even those that could be easily handled by a middle layer) with code in the affected backend and frontends, instead of just using a middle layer for everything it could be used for, and then resorting to a much smaller amount of hard-coding.  There may very well be good reasons that we just haven't thought of, but right now I can't come up with any, which is making it hard for me to understand your lack of a middle layer.

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com