pure transit server

[Fabien Tassin]

According to Russ Allbery:
> 
> Fabien Tassin <fta at sofaraway.org> writes:
> 
> > speaking of conf files, IMHO, we have too many.
> 
> Amen to that.  Way, way too many.

Let me start by remembering that my proposal was to reach the nirvana meaning
that it should be the goal. I don't pretend to be able to achieve that.
I just offer my own ideas hoping that offers will share theirs.

> > ===
> > 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.

In my view, "Incoming" is a name, not a keyword.
 
> >     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.

I don't think the nirvana contains cryptic flags but nirvana is unreachable 
after all ;)

> >   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?

remember that "Outgoing" is not a keyword. Lets change it into "bar" or "1".
A peer can have as many terms as he wants.
A term is composed of two things, a set of conditions grouped in the "from"
block and an action that will be done only if all the conditions are met.
Here, the action is "send", which is not defined in the proposal.
It is bad here but I was thinking to INNT and its builtin outgoing system.
In my thoughts, there is a set of generic actions such as "accept" / "reject"
(using the builtin incoming system), "send" / "drop" (using the builtin
outgoing system) and "pipe" (using a user specified outgoing system such as
innfeed, innxmit, inpaths, etc.).
This action can require arguments of some sort that are specified in the
"then" block. 
Terms and Peers have labels to be referred by.

The idea behind this is to group things and make them dynamic.
I want smooth and smart reloads.  Each keyword will have its hook defining
what to do if the value is created, changed or destroyed.

> 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
> }

I see several problems here.
This is insuffisant to define splitted-by-size outgoing peers.
You are melting conditions to be met and actions to be taken into the
same semantic. You make a one for one association between incoming
and outgoing parameters which is almost always wrong.

> 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).

I see this as named "condition" blocks in addition to "peer" and
"program". 

condition small {
  groups "*";
  size  128KB orlower;
}

condition big {
  groups "*";
  size  129KB orgreater;
}

peer foo {
  term tome {
    from addresses [ news.foo.org 1.2.3.4 ];
    then accept;
  }
  term fromme1 {
    from condition small;
    then {
      address news-small.foo.org;
      send;
    }
  }
  term fromme2 {
    from condition big;
    then {
      address news-big.foo.org;
      port 456;
      send;
    }
  }
}

It can be reduced if we decide that "send" can have in argument a hostname.
  
> > 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.  :)

I'm not either but I see some advantages such as beeing open and most
importantly, beeing free of the syntax of your conf file. You just chose
one that you think is good enough and make your parser spit out XML following
a well defined and public DTD. If someone wants another syntax, he just have
to create its own parser. I think it should fit your API everywhere dream :)

-- 
Fabien Tassin -+- fta at sofaraway.org