[Config4gnu-developer] important negatives to adress ASAP

[C. G. <c.g...@tu...>]

Hello,
here is, as I think a very valuable feedback from somebody who looked into CFG 
but choose to reimplement from scratch anyway.


Subject: Re: Don't implement config functionality (hardcoding Config Tools)
Date: Donnerstag, 15. Januar 2004 21:59
To: kde...@kd...
----------  
> _Even_ if config4gnu would not present more than keys and values to
> frontends, or if a programmer does not want to make use of the provided
> forms and wizard
> stuctures, it is still beneficial to use config4gnu as backend.

Yes, it would be.

> If you don't think so and are working on or intending to write and maintain 
> a config tool, I think the time spent grasping how well config4gnu is
> designed is very worthwhile can actually save a real lot of time in the
> long run. The more fun part of implementing cool frontends can stay but the
> work implementing specifics should be put and shared in the CFG layer
> between apps.

I've had a good look at CFG over the last few days.

My position is this: I've got a User&Group util that depends on libuser.
libuser is only used on Redhat and Mandrake at the moment, and doesn't appear
to be developed much these days. (It doesn't even have a real home page, just
CVS). It is also sub-1.0. So I'm thinking of replacing it with something else
(probably python code). I also have a daemon/system service util that works
well on Mandrake and needs to be ported to Debian. (It looks easy enough
judging from Knoppix). I also have a mount util that is half done (/etc/fstab
is no problem, most of the work in GUI based). Those are the kinds of
problems that I'm facing.

My conclusions about CFG:

1) Incomplete, the framework appears to exist but without backends and
 support for the things that need to do right, it's not very helpful.

2) Development seems to have stopped or slowed considerably.

3) Yet another dependency.

4) There is more to configuring a running system than just editing config
files. What about starting/stopping daemons? Creating and clean up of user
accounts? querying the status of services?

5) The real work is not parsing of writing files, it is doing all the little
jobs like finding out where exactly each distro stores their network config
for example and in what format. See point 1).

and finally:

6) I can't imagine that hacking on a new framework/code base written in C and
Perl, and then trying to get everything working across 3 different languages
is going to be faster or easier than just continuing to code in Python.

cheers, thanks for your input though.

--
Simon Edwards             | Guarddog Firewall
si...@si...       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."

-------------------------------------------------------