On 03/04/2014 12:38 PM, Rafael Schloming wrote:
On Tue, Mar 4, 2014 at 6:39 AM, Gordon Sim <g...@redhat.com> wrote:
On 03/04/2014 11:00 AM, Rob Godfrey wrote:
The naive approach for a 1.0 address "foo" is (I guess) to look up on the
broker side to see if the given there is an exchange named "foo" (in which
case translate to 0-10 {exchange="foo", routing-key=""}) or a queue named
"foo" (in which case translate to a 0-10 {exchange="",routing-key="foo").
That is what the c++ broker currently does.
In some ways this makes sense, but it also has some undesirable properties,
i.e. the translation process from 0-10 to 1-0 address form depends on the
internal state of the broker, and that state may change over time.
It's the translation process from 1.0 to 0-10
For
example, say you have a sequence of messages that are initially resolved to
a queue named "foo", then part way through that sequence someone creates an
exchange named "foo".
Introducing ambiguity about the node name is I think an explicit
alteration of the meaning of the name. It would affect the creation of a
link over 1.0 and even the creation of a sender/receiver using the
qpid::messaging API over 0-10.
It feels top me in the same class of scenario as deleting and recreating
a node of a given name (though clearly its not exactly the same and is
easier to do by accident).
So at present I'm personally inclined not to worry about this too much,
i.e. consider it a corner case and advise people not to do that :-)
You now have a mix of live messages some of which
have address {exchange="", routing-key="foo"}, and others of which have
{exchange="foo", routing-key=""}. It seems unlikely that the application
would actually want a single stream of messages all sent to the same
address to end up with a mix of semantically different addresses when they
come out the other side of the broker.
One option to consider would be to define a special exchange with a
reserved name that knows how to interpret 1.0 addresses. That would allow
you to perform a simple stateless/stable translation of any 1.0 address
into something like {exchange="$amqp1.0", routing-key="<address>"}. This
has the benefit that translated address will always have the same semantic
meaning over time. The one drawback is that the address might not work as
well with other brokers if they don't recognize the "$amqp1.0" exchange,
however I suspect if the 1-0 reply-to address is ultimately intended for a
federated broker, then translating it based on the internal state of its
current broker is not necessarily the right thing either.
Sounds interesting certainly. My main objective was getting simple
client-server applications working when the two parties were using
different protocols (but the same broker). I'm sure more sophisticated
schemes can be constructed if/when someone has sufficient need and/or
desire.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
