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. 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". 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.
--Rafael
