INN's config parser

[Aidan Cully]

On Thu, Jun 21, 2001 at 03:58:09AM, Russ Allbery said:
> Aidan Cully <aidan at panix.com> writes:
> > ftp://ftp.jalacy.com/pub/src/gucs-inn-demo.tgz
> 
> Thanks for the example!
> 
> This looks quite nice if we were go to the generated parser route.  I
> think there are enough other reasons to not take that route that the route
> that I took is better for INN, but your approach definitely also would
> have worked.  The part that I'm not fond of about it is that it integrates
> knowledge of the types and valid parameters very tightly into the parser,
> so it's harder for programs that don't care about many of the parameter
> values to be able to still use the same configuration files without
> needing the full parser, or to be able to combine all configuration files
> for all of INN into a single logical configuration file that includes
> other ones and just have programs ignore the parts they don't care about.

One of my goals was for syntax checking to be tightly integrated, so
that if a config file worked for any individual client of that file,
it was (to some extent) guaranteed to work for other clients of the
file.  That's one of the main reasons I preferred the generated route,
vs. most of the parse-then-query interfaces I've seen...  If you can
ignore part of the syntax, then it can become difficult to detect, or
even figure out how to detect, typos in the rest of the config file.

As for merging all config files into one giant file, that could still
happen without too much effort by %abstracting the parsers for the
individual files, and having the main file &{Parse:} them when it runs
into particular keywords...
readers {
	# inside here is the current contents of the readers.conf.
}
could be easily supported.

> I also found that I was able to understand what was going on better with a
> sharp division between the syntactic parsing and the semantic analysis,
> and therefore maintain the code better because once the parsing was done,
> I didn't have to look at it and could treat it as a completely black box.

Yes, the control flow might be a bit wierd through gucs...  I don't
know how to get around that.  I think it's clearer than yacc, at
least. :-)

> > If this is something you think INN would benefit from having, let me
> > know...  I started the project partly because I felt guilty about the
> > readers.conf implementation, and I'd like to try and make up for that.
> 
> Don't feel guilty; it's been a major feature of INN 2.3!  :)

Maybe so, but the code is a mess to work with.

> I don't think we're going to want to go this route, but I very much
> appreciate the example and the thoughts.

Right-o.  Whatever you think's best.

--aidan
-- 
Aidan Cully       "Umm..  Could you call back?  My house is on fire."
Not Panix Staff      --Tom Waits
aidan at panix.com