On 03/28/2013 09:11 AM, Ken Giusti wrote:
At first I was a bit skeptical whether this really belongs in the messenger
API, but I've come to accept that it would have to be. Internally, messenger
does perform routing - mapping the 'to' address to the proper connection and
link. To me, this new API provides a level of control over that mapping
process.
That said, the api needs a bit of fleshing out.
Assuming that we support multiple routes, then most obviously the api would
need to provide the ability to query the route table for a given mapping. I'd
also like to see a means for walking the route table in match order. And
deletions - can't forget that.
And to be clear - the match precedent is determined by the order in which
routes are added, correct? That may be hard to manage if the route table is
modified over time. Perhaps a route should be given a priority? Or maybe we
give routes precedence based on their restrictiveness - matching more
restrictive first?
I am starting to think we need a proton routing plug-in API so that different
choices of routing rules, pattern matching, configuration files etc. can be
implemented without baking one set of choices into messenger. Such a plugin API
could be fairly simple and would allow choice and composition of functionality
from different plug-ins.
----- Original Message -----
From: "Rafael Schloming" <r...@alum.mit.edu>
To: proton@qpid.apache.org
Sent: Saturday, March 23, 2013 12:43:07 PM
Subject: RFC: new routing functionality for messenger
Hi,
I've added a new API to messenger that gives the user some control
over the
internal routing behaviour of a messenger. Please check it out and
comment.
I've pasted the C API/doxygen below. This is currently only exposed
through
the python binding via the route method on the Messenger class.
--Rafael
/** Adds a routing rule to a Messenger's internal routing table.
*
* The route procedure may be used to influence how a messenger will
* internally treat a given address or class of addresses. Every call
* to the route procedure will result in messenger appending a
routing
* rule to its internal routing table.
*
* Whenever a message is presented to a messenger for delivery, it
* will match the address of this message against the set of routing
* rules in order. The first rule to match will be triggered, and
* instead of routing based on the address presented in the message,
* the messenger will route based on the address supplied in the
rule.
*
* The pattern matching syntax supports two types of matches, a '%'
* will match any character except a '/', and a '*' will match any
* character including a '/'.
*
* A routing address is specified as a normal AMQP address, however
it
* may additionally use substitution variables from the pattern match
* that triggered the rule.
*
* Any message sent to "foo" will be routed to "amqp://foo.com":
*
* pn_messenger_route("foo", "amqp://foo.com");
*
* Any message sent to "foobar" will be routed to
* "amqp://foo.com/bar":
*
* pn_messenger_route("foobar", "amqp://foo.com/bar");
*
* Any message sent to bar/<path> will be routed to the corresponding
* path within the amqp://bar.com domain:
*
* pn_messenger_route("bar/*", "amqp://bar.com/$1");
*
* Route all messages over TLS:
*
* pn_messenger_route("amqp:*", "amqps:$1")
*
* Supply credentials for foo.com:
*
* pn_messenger_route("amqp://foo.com/*",
"amqp://user:passw...@foo.com/$1
");
*
* Supply credentials for all domains:
*
* pn_messenger_route("amqp://*", "amqp://user:password@$1");
*
* Route all addresses through a single proxy while preserving the
* original destination:
*
* pn_messenger_route("amqp://%/*",
"amqp://user:password@proxy/$1/$2");
*
* Route any address through a single broker:
*
* pn_messenger_route("*", "amqp://user:password@broker/$1");
*
* @param[in] messenger the Messenger
* @param[in] pattern a glob pattern
* @param[in] address an address indicating alternative routing
*
* @return an error code or zero on success
* @see error.h
*
*/
PN_EXTERN int pn_messenger_route(pn_messenger_t *messenger, const
char
*pattern,
const char *address);
