inn.conf parsing

Russ Allbery rra at stanford.edu
Mon Apr 10 05:48:14 UTC 2000


[ Old discussion about inn.conf parsing. ]

Forrest J Cavalier <mibsoft at mibsoftware.com> writes:

> Not sure what happened to my first reply...Never got it back from
> the list, so here is a replacement.

>> This should really be done like in Squid, i.e. from a single file which
>> contains the specification and documentation of all available options
>> everything else is generated (including man page, etc).  Ideally,
>> introducing or obsoleting an inn.conf option would require a change in
>> exactly one source file.

> Good idea.  I put it into the INN 2.x in February 1998.

> http://www.mibsoftware.com/userkt/inn/dev/inn-workers/vol9802/xiu.htm

> Dave Hayes even wrote a perl script to support the (pretty minimal) file
> parsing and insertion involved.  It was slick, I think, because it
> collected all of the code into one file.  I used it.  No one else did.

> Somebody removed the capability since then.

This, or something like it, will probably be back in INN 2.4.  I want to
revamp how the parsing is done first, though.  The current parsing is far
too code-driven for my taste; I'm looking at replacing it with a
data-driven parser that uses an array of variable names, variable types,
offsets, and default values.  That should simplify the parser quite a bit
and then I can take a look at generating that, the POD file, the sample
inn.conf file, and the innconf structure definition from a single source
file.

I'd really like to take a look at what inn.conf parameters we can get rid
of too, though.  Right now, I have the feeling that we have a few too many
options, and that some of them have outlived their usefulness, are safe to
just replace with their default value, or could be eliminated via a
feature added elsewhere (for example, a new newsfeeds flag to give the
Path tail could eliminate the need for the logipaddr parameter, I
believe).

It also may be worth seeing what inn.conf parameters are only used by some
particular programs and could be moved to more specific configuration
files.  I think a whole bunch of them belong in readers.conf, for example,
and there are some that could be moved to incoming.conf.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the inn-workers mailing list