INN config file parsing infrastructure

Todd Olson tco2 at cornell.edu
Mon May 1 12:47:32 UTC 2000


Hi

>The goal is to implement one configuration file parsing library that all
>parts of INN can use and which understands one standard syntax. 
>[...]
>
>
>A parameter takes the form:
>
>    parameter: value
>
>[...] 
>Parameters are of three basic types:  strings, numbers, and booleans.  (We
>may want to divide numbers into ints and longs).  Booleans use the same
>syntax as inn.conf does now, namely that any of "true", "yes", or "on" are
>valid, and probably "1" as well.  The value is checked to make sure it
>matches the parameter type.

What about parameters with no values (such as innflags: in inn.conf) ??
Currently if there is just white space inn complains about the parameter.

>
>Values, regardless of type, may be enclosed in double quotes.  They must
>be enclosed in double quotes if they contain any whitespace, or either of
>the characters '}' or ';'.  Inside double quotes, a backslash escapes the
>next character, regardless of what it is, and can be used to put double
>quotes in the string and to continue lines.  Note that something like:
>
>    parameter: "first line\
>        second line"
>
>would result in a literal newline being part of the string assigned to
>that parameter.


Hum ... I'm having trouble deducing how you will handle the case
where I want to write 
     parameter:  first_token \
          second_token

and have it mean
     parameter:  first_token second_token


>Whitespace between the colon and the first non-whitespace character or
>opening quote of the value is ignored.

and if there is not a first non-whitespace?

>
>Parameters may occur at the "top level" of the file, or they may be
>enclosed in groups.  In the underlying implementation, the top level of
>the file is an implicit group.  Different parameters may be valid inside
>different groups.  A group contained inside another group (bearing in mind
>that the top level is an implicit group) inherits the values of any
>parameters that it has in common with its enclosing group.
>
>The syntax for a group is:
>
>    name tag {
>       ...
>    }
>
>The name is chosen from a fixed set of possible groups, with the same
>range of valid characters as parameters.  tag is an arbitrary
>user-supplied tag and is subject to the same quoting rules as parameter
>values.  (Some configuration files may put additional restrictions on the
>tags, of course.)

The group idea is very useful ...
But it could become hard to figure out by hand from the config file
what value is set for what.  It seems essential to the infrastructure
to have a tool (based on the parse library) that allows you to ask
    1) for this "group" what are all the parameter:value pairs
       set explicitly or implicitly
    2) which of these are set only be defaults built into inn

Hum ... #2 raises the question of defaults built into code.  Perhaps
all defaults should be collected into one location at least for use at
build time, if not for run time.  

And in the case of something like readers.conf it a tool that let you
on the command line enter a particular address & and userid and show
how they were rejected or accepted by the different stanzas would 
be a useful debugging tool.

While I'm at it a similar sort of tool for testing particular newsgroup
names against wildmats (eg in incoming.conf) would be useful for testing
and developing wildmats.


Regards,
Todd Olson




More information about the inn-workers mailing list