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 

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


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
I've pasted the C API/doxygen below. This is currently only exposed
the python binding via the route method on the Messenger class.


/** 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
  * 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
  * 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
  * 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/*",
  * 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://%/*",
  * 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
                                  const char *address);

Reply via email to