Re: [Config4gnu-developer] Re: [libconf] libconf, config4gnu

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

On Wed, 2002-10-16 at 12:08, dams wrote:
> "Jason Long" <jl...@me...> writes:
> 
> > I apologize for not responding earlier. I've been delaying because I haven't
> > really decided yet. :)
> > 
> > However, I think our projects do have slightly different scopes. Here's how
> > I would explain it, and be sure to correct me if I am mistaken.
> > 
> > libconf-
> >  provides a library for creating / manipulating a configuration file. It
> > will know about the different formats. The user has to specify what file the
> > configuration setting is in, but doesn't need to know about the internal
> > format of the file.
> > 
> > Config4GNU-
> >  tries to provide front-ends for accessing configuration settings for the
> > whole system. Settings from all sorts of different files will be accessible
> > through a hierarchical data model. Users who want to make a setting change
> > don't need to know what file it's actually stored in or what the format of
> > the file. However, Config4GNU must know about the file and what format it's
> > in.
> 
> 
> well, that would be true if libconf was alone :)
> But libconf is only a layer, another layer will be built on top of it, to
> abstract the location and the unicity of the information.
> 
> > 
> > That said, I think there's a great opportunity for collaberation here. The
> > way I see it, libconf could provide all of the parsing of and manipulation
> > of configuration files for Config4GNU.
> 
> ok, why not :)
> right now the templates supported are :
> 
> XF86Config
> Sshd
> Samba
> Shell (a tons of files are supported with this template then)
> Apache
> Values_section (idem, this is a generic template)
> 
> I think we are moving faster than you on the first layer, maybe it would be
> good that config4gnu provides the upper layer

Certainly you have a much larger list of config files that our parses
support.  We have one parser for ini-style files (Samba, PHP, etc.) and
one for colon delimited files (passwd, shadow, group, etc.), which could
easily be modified to parse other similarly-delimited files.  A question
I have is whether your Samba parser also parses php.ini, and whether
your Apache parser also works for ProFTP (which uses a *very* similar
format).  We had been planning to create generic parsers that weren't
aware of which directives were allowed in what sections, etc.  This
would allow a smaller number of parsers to be written and used.  

My second question is your reason for going with a perl data structure
for passing the data.  Our system is built around XML to allow any
language to interact with the data.  It wouldn't be hard to run the perl
data through a script that made it into XML, but I'm just curious as to
why you made that design decision.

Finally, we were planning on having a middle layer which was basically
the brains of the whole thing (since both the parsers and the front-ends
don't really know much about whats going on).  Am I correct in assuming
that such a middle layer isn't provided by libconf?

I think a very important first step if we were to work together is to
standardize the communication between libconf and c4g's components and
stick to that standard.  We've developed a format for communication
within c4g, but we'd certainly be open to suggestions/improvements.  I
think the main thing is to have it be language-independent and to be
general enough so that the front ends can easily understand it without
having to be programmed to understand more than a small handful of XML
tags or data structures.
 
Justin