Re: Don't implement config functionality (hardcoding Config Tools)

On Wed, 14 Jan 2004 08:29 pm, C. Gatzemeier wrote:
> I had a look at the "guidance" config tools, are they the ones intended for 
> kde-debian?

I haven't heard any official word myself, but I assume so. ;-) 

(Who's in charge here anyway?)

> Am Sonntag, 11. Januar 2004 23:53 schrieb C. Gatzemeier:
> _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
[email protected]       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."