I think this is confusing, because the link origins seem a little router-centric, while the link message directions are client-centric.
Why not make everything rclearly router-centric, in this context. Like this: links made by clients are "client links" (or "client-originated links") links made by routers are "router links" (or "router-originated links") links pointing at clients are pointing "outward" links pointing at routers are pointing "inward" links between two routers are "internal" ----- Original Message ----- > Direction of message flow is tricky to describe in router > configuration. "in" and "out", "sender" and "receiver" all have > opposite meaning depending on whether you are thinking from a router or > client perspective. > > Here's what I would propose based on the existing use of "in" and "out" > in the linkRoutePattern configuration. This is the opposite of how I > usually think of "in" and "out" but I suspect this is a 50/50 issue > where it doesn't matter which we pick as long as we pick one. > > Note I'm using "relay" to mean router-initiated links, which currently > means waypoints and link-routes. > > ======================= > Directional terminology > ======================= > > Connections: can be established to the router (via listeners) or from > the router (via connectors) The direction that the connection was made > has no effect on how it can be used. > > Links opened from outside the router are "client" links. Links opened > by the router are "relay" links. > > Links that receive messages from the router network are called *in* > links because messages flow from the network *into* a client or are > relayed *into* an external system. > > Links that send messages *to* the router network are called "out" links > because messages flow *out* of clients or external systems to the > network. > > > Shout if I've got this wrong or if anyone has ideas for less ambiguous > terms than in/out or send/receive. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
