[Config4gnu-developer] project tasks/design proposal and thoughts on libconf

[Justin Y. <ju...@sk...>]

There are a number of people on the developer mailing list.  I encourage
any/all of you to respond to this message (and all messages on this list
for that matter) with your input.  Jason and I can't do this ourselves,
and I know many of you want to help.  If something isn't clear, it may
be one of those things me & Jason discussed face to face, so feel free
to ask if you're confused.

Part of this email is an attempt to document face to face communication
between me & Jason, and the rest is a transcript of conversations I've
had with myself in the past few days... :)  I welcome any & all
clarifications & disagreements, I certainly don't claim to have all the
answers.


Proposed Design/Tasks plan:

Stage 1) Finish design of XML and decide on standard format/tags for
it.  Make at least 1 parser and GUI which can handle this XML properly
for demo purposes.  The middle layer is mostly a dummy layer at this
point.  At the end of this stage, we've got a working program, but it is
considered beta and lacks a lot of important/fancy features.  Target:
Dec 2002 - Jan 2003.

Stage 2A) Develop each layer more or less independently of eachother. 
We would add maybe one or two more front-ends, parsers for most config
files, and incorporate context-sensitive documentation inside the
front-ends for *each* configuration directive, as much as possible. 
Some of this can be accomplished by parsing man pages, etc.

Stage 2B) Possibly independently of 2A, this stage involves adding
"required" features to the middle layer.  Things like checking to make
sure that the user's configuration is sane, adding logging and undo
features, adding support for applications/daemons to read their
configuration as XML via our libraries (instead of parsing them
themselves).  At the end of this stage, we've got a 1.0 release. 
Target: Early-mid Spring 2003 (March?).

Stage 3) Improve stability and speed, smooth over any rough edges not
already taken care of in the design of everything.  At the end of this
stage, we should be ready for a 1.2 release, and should really start
convincing distros & software maintainers to include our stuff.  Target:
early Summer 2003 (May?).

Stage 4) Add support for configuring many more things.  Provide
configuration data so C4G can handle all common things under GNU
systems.  Maybe add library for programs to use C4G to access their
config files at this stage instead of in 2B.

Stage 5) Possibly add modules to existing configuration tools (webmin,
linuxconf, etc.) which allow those configuration tools to manipulate our
configuration data.  Not sure if this is really necessary, but its an
idea.

Stage 6) Maintain compatibility with current software as necessary,
although by this point we shouldn't need to do much at all.



Now, here are my thoughts on Libconf...

I think using Libconf could be a good thing, but I see the following
issues arising:

- C4G and Libconf should be packaged and released together, or at the
*VERY LEAST*, new releases should be synchronized.  My worry is that
especially during the early stages, we will be tweaking things a lot
(including the communication between layers/components), and this could
easily break things.  That would be a pain for testers during
development, and maybe even worse once C4G is ready for production
environments.

- XML should be used for communication using a standard XML structure. 
This allows things to be written in languages other than Perl without
much messyness.  Maybe we could even use a custom XML storage library
and write wrappers for it in the various languages so the XML doesn't
have to be re-parsed (Is this possible/worth it??)  

Anyway, I think only the parser/backend layer should be written at all
in Perl.  The rest (certainly the GUIs) should be written in C and
should be lean and fast, I can't stand slow GUIs (Nautilus comes to
mind...).

- It seems that developing C4G will require constantly revising the
middle layer as we need to.  If Libconf provides this layer, it could
easily end up being a bottleneck to get the Libconf developers to make
the changes (unless some of "us" become libconf developers?).  If we
provide the layer, libconf will also need to access & modify the code
frequently.  This presents a big problem.  

Two solutions are to 1) Make C4G handle front-end stuff, libconf handle
back-end stuff, and a third project handle middle stuff, or 2) libconf
makes the back-ends, C4G makes our front-ends, and each project develops
a middle layer separately.  

If we pick #1, then there are going to be a lot of "cooks in the
kitchen", and that may (or may not) cause some problems & differences of
opinion, resulting in forked code.  It may also be difficult for two
brand new and not fully working projects to depend on eachother for
certain parts...

If we pick #2, then we almost may as well write our own parsers to work
with our XML format instead of coercing libconf to write parsers that
work the way we want them to.  Are parsers *that* hard to just write
ourselves?  Is there any other possible option?  I don't want to
duplicate work, but I don't know what to suggest here.

- I'm still trying to understand what exactly libconf will provide and
how it differs from our project from a design standpoint.  I've read
most of the Libconf docs, but its still fuzzy, and I've yet to get ahold
of anyone online on IRC.  Note that this isn't necessarily the fault of
anyone responsible for Libconf.


Justin

-- 
SkiingYAC.com
Custom Solutions
su...@sk...
http://www.SkiingYAC.com