INN config file parsing infrastructure

Olaf Titz olaf at bigred.inka.de
Tue May 9 10:03:13 UTC 2000


> Anything you like about other ISC software's (BIND, DHCP) configuration
> files that could be used?   A little consistency among the ISC systems
> might be nice (perhaps even code re-use?).

The BIND configuration leads into the right direction already, but
what Russ has proposed is a more or less generic parser which can
ultimately be split off as a separate library and reused for other
packages as well, and I agree violently on that part of the proposal.
It's a thing today's complicated Unix packages have lacked for years,
each one comes with its own config file stuff. You can see in the
various parts of INN where this leads.

Have you ever seen the source for the Dante (socks package) config
file parser? It uses roughly the same syntax as BIND, with a parser
written in yacc which is just royally broken; among other things it
imposes a fixed order on all the options - but that is what you get
when you just code away without spending too much time on design.
BIND's - also in yacc - is much better but it doesn't contain any
generic code, you can just take it as an example.

I have thought about an approach very similar to Russ's a time ago. My
idea was a parser-generator for config files, driven by a description
file using about the same syntax. What I have in mind is best told by
a simple example: the template for storage.conf (with the class number
as identifier, as I've explained earlier would be the right way) could
look like this:

token {
    # define lexical tokens used below. This is just syntax.
    # We could of course bundle them into an include file
    WILDMAT: "[A-Za-z0-9,!*.-]+";
    METHOD:  "trash|timehash|cnfs|timecaf|tradspool";
    EXPIRES: "[0-9]+[dm]?"
    TWONUM:  "[0-9]*(,[0-9]+)?"
}

group "class" NUMBER {
    newsgroups: WILDMAT mandatory;
    method: METHOD mandatory;
    expires: EXPIRES;
    size: TWONUM;
    options: STRING;
}

The "token" group is to generate rules for lex; the result would be
one lex and one yacc file for each config file to be parsed.
(However, using lex/yacc for everything is probably overkill.)

Olaf




More information about the inn-workers mailing list