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

[dams <da...@id...>]

Justin Yackoski <ju...@sk...> writes:


[...]

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

yes, php.ini is supported by value_sections, and proftpd should work, I have
not tested. But I shortcuted the explanations. these templates are basic
templates, that is templates for a family of config file, not one. Then ames
are not very good, but the templates works for multiples config files. another
list is built from them at run time, a list of templates that are bonded to one
specific config file. I'll explain the stuff later. It's like major and minor
mode in emacs

>  We had been planning to create generic parsers that weren't
> aware of which directives were allowed in what sections, etc.

our templates (basic and specific ones) are _not_ aware of which directives are
allowed. That part is handled by the validation system, that is working, but
not like I would like to. I'll recode it shortly


>  This
> would allow a smaller number of parsers to be written and used.  

That's also the goal. For example, the comments will not be stored in the basic
templates, but in the specific ones. I'll code this next week-end if I'm lucky.

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

there are 2 reasons, that are in the doc (go and read it :
http://www2.damz.net/files/libconf_doc.html
) :

-first one, I plan to use xml, but I build the core in perl. I have not build
 the xml stuff _yet_ but I will. But not shortly, because we don't need it now.
-the second one is that the software that uses libconf won't be obliged to grab
 the data ! It can get it, work with it, and give it to libconf, but libconf
 has a set of built-in functions to edit the data tree directly (documented at
 "features" in the doc). So when the C/python/whatever binding will be done,
 libconf will be fully useable, even if you don't have an xml parser (and you
 don't most of the time, when you are coding small config tools). So xml is
 good, but not needed.

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

It will be. It's the layer on top of libconf. Now if you want to code it,
you're welcome :)

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

well, libconf and config4gnu use perl, so I suggest that we have a fast way to
tranfer the data, by passing perl structure. We could discus on that structure.
The libconf one is not frozen now.

if you want, you can see us on #libconf@OPN