unified conf syntax proposal..

Russ Allbery rra at stanford.edu
Sun Mar 11 06:06:25 UTC 2001


Fabien Tassin <fta at sofaraway.org> writes:

> I've planned to implement a parser for the following syntax RSN.

Is there any way that you could use the syntax that we previously hashed
out for INN's configuration file?  It looks like you're doing something
*almost* similar, but just different enough that we couldn't use the same
parser, and I think that the existing syntax could still do what you want
to do.

It would be really unfortunate if we couldn't use the same syntax for all
of INN's configuration files.  :/  I suppose it's my fault for not having
managed to finish writing that parser yet.

I'd also recommend against the default group and stuff like "no default";
I think it adds confusing linkage between different groups that aren't
obviously nested.

The idea of defaults can be handled with nested groups that inherit all
properties from their enclosing groups unless they're explicitly
overridden; it's then easier to tell at a glance what properties apply.
I think a descriptive approach to feeds would be much clearer, like:

peer foo {
    accept {
        groups: "*,@*poison*"
        address: "news.foo.org, 1.2.3.4"
    }
    feed {
        condition: "small"
        exclude-path: "foo, news-small.foo.org"
        address: news-small.foo.org
        port: 456
        type: builtin
    }
    feed {
        condition: big
        exclude-path: "foo, news-big.foo.org"
        address: news-big.foo.org
        port: 456
        type: builtin
    }
}

I don't think you're actually gaining anything from the "condition then
action" syntax model; the above expresses the same thing without requiring
that additional structure.

That has all the same information as your example, but the syntax elements
are much simpler.  No special syntax for lists (although I could be argued
into [] instead of a de facto standard of comma-separated lists -- there's
a good justification for adding that syntax element), a uniform syntax
that always has "key: value", and the same syntax as incoming.conf,
readers.conf, or innfeed.conf so that we can use the same parser for all
of them.

I don't care much about whether the accept and feed blocks have labels;
I'm happy to have the syntax allow either putting in labels or leaving
them off, actually.

I do actually care a lot about keeping to a "key: value" syntax if at all
possible, if it doesn't make much difference to you.  That sort of detail
doesn't change what the syntax can express, but it makes a *huge*
difference when writing the parser and using the same parser for
everything.

> - are 'option's in a program block needed or not ? This is the place for
>   non-peer outgoing parameters but there's no way to use them except for
>   'builtin'.

I'd use a completely separate block for global settings, probably called
something like "global".

> - Some (including Russ) dislike named terms. I agree that the names are
> useless in the semantic but I want to be able to manipulate terms by
> name like in 'ctlinntd del peer foo term fromme1'.

Yeah, that's a good reason for them.

Okay, assuming that we add [] for lists, where a value is expected, the
syntax that I'm proposing has the following semi-formal description:

    group         := <type> *1(<space> <name>) { *<item> *<group> }
    type          := <label>
    name          := <string>
    item          := <parameter> : (<string> / <list>)
    <parameter>   := <label>
    <string>      := <label> / " <quoted-text> "
    <list>        := [ <string> *(<space> <string>) ]
    <label>       := 1*(A-Z / a-z / 0-9 / _)
    <quoted-text> := *(any character, \ escapes " or newline, standard
                       C backslash escapes apply)

Whitespace can be placed arbitrarily anywhere except in the middle of a
label (and is significant in quoted-text), about as you'd expect.  There
are two places where at least one space is required; between elements of a
list, and between the type of the group and the group name if given.

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


More information about the inn-workers mailing list