INN config file parsing infrastructure

[Russ Allbery]

Aidan Cully <aidan at panix.com> writes:

> If you're willing to change the syntax to be more line-oriented, allow
> me to show you a syntax I've been using in a local project.  The
> following groups are all equivalent:

> in main file:
> group "name" {
> 	param: "string"
> }

Want this, definitely.

> group "name" param: "string"

I'm not sure how important supporting this is, since in my proposed syntax
one can equivalently say:

    group "name" { param: "string" }

to do the same thing and use the same parser as that which parses the
first example.

> group "name" include "file1"
> group "name" {
> 	include "file1"
> }

Here, I think the second one is a really good idea; same comment as above
on the first once we have support for the second.  I like the idea of an
include inside a group; it'll be a bit interesting to implement in the
parser, but I think the results will definitely be worth it.  For example,
I can envision a CGI application that you can point your peers at that
will allow them to edit only their portion of your newsfeeds file.

> The interesting line, to me, is 'group "name" include "file1"'.  Neat
> properties of this are:
>  * it can seperate out administrative control over different parts of
>    the configuration.

Yup, agreed.

>  * you could provide backwards-compatible support for inn.conf (and to
>    a lesser extent, incoming.conf, storage.conf and readers.conf),
>    while still allowing for all configuration to happen in a single
>    file, if you want.

> A 'news.conf' file could look like:

> options include "inn.conf"
> incoming include "incoming.conf"
> readers include "readers.conf"
> storage include "storage.conf"

That's a rather interesting idea.  I'm not quite sure what I think of it
yet, but it's worth considering.

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