pure transit server

Russ Allbery rra at stanford.edu
Thu Feb 8 20:54:58 UTC 2001


Fabien Tassin <fta at sofaraway.org> writes:

> speaking of conf files, IMHO, we have too many.

Amen to that.  Way, way too many.

> I'll try to elaborate later but I'm tempted by a file called
> newsfeeds.conf to replace incoming.conf, innfeed.conf and newsfeeds. It
> will contain 2 types of sections, "peer" and "program". Usage of
> conditions can produce powerful things..

Yup, sounds like the model that I had floating around in my head.

> ===
> peer foo {
>   term Incoming {

In the previous discussion, an excellent point was made that the "name"
slot in groups should really be a name, not something that's repeated for
other groups, so that you can talk about a group by name.  I think that we
also want unnamed anonymous groups so that one doesn't have to give
everything a name if one doesn't want to and it doesn't matter (cf
readers.conf).  Which basically reduces to writing this as:

    incoming {

instead.  But that's a syntactic detail.

>     from { 
>        addresses [ news.foo.org 1.2.3.4 ];
>        groups "*, at poison";
>        size 1024KB orlower;
>     }
>     then accept;
>   }

As a first pass, I recommend having a flags: parameter with all of the
same cryptic notation as the current newsfeeds file.  We already have all
of the semantics of those flags worked out, and there will be stuff you
can specify with flags that we don't have a nicer way of saying for quite
some time.

>   term Outgoing {
>     from {
>       groups "*";
>       size 128KB orlower;
>     }
>     then {
>        address news-small.foo.org;
>        send;
>     }

I don't like the "then" blocks.  What are those doing for you in this
context?

Other than that, I like the basic idea, and I think that's about the right
information.  I'd add an additional field called feed-type, so that you
could write something like:

peer foo {
    accept-from: "news.foo.org, 1.2.3.4"
    accept-groups: "*, at local.*"
    feed-to: peer.news.foo.org
    feed-groups: "*"
    feed-type: innfeed
    feed-size: <128KB
}

You want to be able to nest peers inside larger groups so that you can set
some defaults at a higher level and have them all inherited.  To fit into
that model, I wouldn't use the incoming/outgoing groups, since you want
all of the parameters to be uniquely named so that the above works (you
want to be able to set a default accept-groups and have it inherited by
all the peers in a group and not have it conflict with what groups you're
feeding out).  Instead, I'd just use something flat like the above (which
actually looks a lot like the templates that people are already using for
feeds).

feed-type can be innfeed, batch, or maybe internal (or ignored) by inntd,
to take care of the most common Tf,Wnm and Tm:innfeed! feed types that
people currently use.  You could use "feed-type: program <name>" to
specify that one should feed into a program, so something like:

peer pathlog {
    feed-groups: *,!local.*
    feed-type: "program inpaths"
}

program inpaths {
    command: "/news/bin/inpaths"
    type: channel
    data-wanted: paths
    arguments: "-p -d /news/log/path/inpaths.%d"
}

> I'm wondering if an internal XML API will not be a good thing..

I'd like to write something that's easy to convert to XML if people really
want to, but I'm likely to leave the XML to someone else.  I'm not a
convert to that religion, at least yet.  :)

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


More information about the inn-workers mailing list