INN config file parsing infrastructure
Russ Allbery
rra at stanford.edu
Mon Jun 26 02:59:12 UTC 2000
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/>
More information about the inn-workers
mailing list