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