Re: [Config4gnu-developer] important negatives to adress ASAP

[Jason L. <JL...@me...>]

These are all very good points. In fact, they very much echo a lot of my
concerns about the project. I'll try to comment on some of those points...

> 2) Development seems to have stopped or slowed considerably.

Agreed. Actually, I've been doing coding but it's on my side-project
playing with WBEM. I'll send a separate email explaining what I've been
doing with that.

> 3) Yet another dependency.

It is. Finding the balance between not reinventing the wheel and not having
unnecessary dependencies is difficult. I have already stated that I'm tired
of the Xerces dependency (XML library) and would like to use the more
commonly installed libxml2 library instead. Unfortunately, the two libraries
use significantly different APIs, so it will require a bit of coding to do
that.

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

This is one of the reasons I've been looking at different approaches,
including CORBA and WBEM. There are ways these things can be accomplished by
continuing to pass XML back and forth, but it just starts to get clunky in
my opinion.

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

That is true. However, there needs to be some sort of established framework
for doing the parsing and writing of files. I'm not sure if one exists. So,
Config4GNU got started with the intention of making it easy to
programmatically implement changes to configuration files without worrying
about what format the configuration file is in. I know the libconf project
started out the same way, using some different techniques. The idea is that
once we made that part easy and had other parts of the framework in place,
then we would go around and add support for many distributions and
applications.

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

Our parsers, written in Perl, currently link to our main Config4GNU
library, written in C++. Sometimes I'm amazed this actually works. And I
have to imagine that it will be difficult trying to port it to some other
platforms, where the C++ compiler acts differently or shared libraries act
differently...

Working completely in one language has its advantages, for sure. However,
it seems all too common that things get reimplemented in a given language
rather than use existing libraries/modules written in other languages. This
is because the work to link those different languages together (and the
resulting dependency issues) is much more work than just reimplementing the
code.

One of my goals with the Config4GNU project (I can't remember if this is
actually listed on the website) is to create a system where people can write
various parts of the system (parsers, front-ends, etc.) in whatever language
they prefer or need to do the task. Configuration files are not always
stored in text files on the local system. Sometimes you might actually need
to load a library in order to read/write configuration of a specific sort.
If you tie yourself to a certain language, you may have to reimplement that
library to get at that configuration.

Unfortunately, Config4GNU's way of programming language independence is
very limited. In my opinion it is going to take quite some time to truely
attain the kind of programming language independence that I would like to
see.

--

Ok, this email is getting a little long. Peter, your suggestion about
having a development weekend is great. That's exactly the sort of think that
I personally would need to help feel more focused and optimistic about this
project. Justin-- what are the chances we could actually make time to get
together and do some coding? :)

Jason




>>> p.c...@ar... 1/16/04 10:30:26 AM >>>

Hi,

I think the feedback gave a valuable insight into how CFG in perceived.
Some
things have to be dealt with coding some with information. I can't code
but I can start a wiki page on freedesktop.org end of next month. I can
adress some points, but for other things I would need some base for a
start.

A good idea I saw at the skolelinux project is to schedule a
development weekend. It showed ppl realy like to hook up and work
together even meet if possible rather than just kind of
lonely, individually.

Planning a weekend aiming for a test-suite release, some examples,
and basic notes on how to add support (meta-data) for more apps can be a
good idea. (Maybe additionally providing staticaly linked binaries for
easy testing  might be a viable workaround for the moment as long as
some depreciated dependencies can't be removed)

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

=> Testing release with a meta-data directory standard for additions,
plus an initial quick guide how to support additional apps? (Also
continous collaboration of testers and users on improving that guide
on the wiki and documenting experiences.)


RFC on the following points. Are they just not perceived right? What is
actually already solved in CFG?

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







-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn 
_______________________________________________
Config4gnu-developer mailing list
Con...@li... 
https://lists.sourceforge.net/lists/listinfo/config4gnu-developer