[rabbitmq-discuss] Simpler STOMP Behaviour

[Michael Bridgen]

>> This design proposes to remove the custom headers, and use only the
>> `destination` header with compound values that define the exchange,
>> routing key and queue names.
>
> Rob,
>
> This looks very good.
>
> There is one additional use case which is often needed: private
> temporary queues to get replies back. This maps to the Return Address
> concept in Enterprise Integration Patterns.
>
> Is this something that could be done with your proposed syntax?

Since there's no reply from the server to SUBSCRIBE, and we generally 
want reply queues to have different properties to shared queues, really 
the only option is to have a distinguished prefix for reply queue 
destinations, and require clients to supply their own (preferably fresh) 
names.

For example:
SUBSCRIBE /reply/<md5 of some client properties>

It might be an idea to use queue leases for these, instead of 
auto-delete, so that a client fronting up after a connection drop has a 
chance of recovering replies. (If it's lost its own state, then it 
should construct a fresh name)

> Also, what about AMQP 1.0? Have you considered it in order to get a
> syntax that can be adapted/extended to the new AMQP 1.0 concepts?

Do you mean using something like /node/ for destinations?

There aren't really any such concepts in AMQP 1.0 to pin a concrete 
protocol implementation to.  It's only a message exchange protocol, and 
just like STOMP, doesn't take an opinion on what is addressable at the 
broker.  Indeed, if we were to make an AMQP 1.0 adapter, we'd have to 
invent some scheme for addressing exchanges and queues there, too.


Michael.