[rabbitmq-discuss] Simpler STOMP Behaviour

[Lionel Cons]

Michael Bridgen <mikeb at rabbitmq.com> writes:
> 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.

In practice, other solutions exist. I'm not sure which one is
preferable.

(1) With ActiveMQ, one can subscribe to /temp-queue/whatever and a
private queue with a random name will be created on the broker. The
client program can send a message to itself, examine the destination
header of the received message and find out this way what is the real
queue name.

(2) We could imagine using the RECEIPT frame to allow the broker to
"reply" to the client. Something like:

  SUBSCRIBE /i-want-a-private-queue
  receipt:123

  RECEIPT
  receipt-id:123
  destination:/queue/004b2782fba54d18576bc2c710b517b1

> SUBSCRIBE /reply/<md5 of some client properties>

This would work too.

>> 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?

For instance. AMQP 1.0 has nodes, queues, links and filters (and no more
exchanges). They should be exposed via STOMP somehow.

In addition, AMQP 1.0 introduced the notion of global addressing,
something like node-name at container. This should also be usable from
STOMP.

However, I'm not up-to-date with what AMQP 1.0 really is today. Concepts
like remote addressing have been described for instance in last year's
F2F meeting:
http://www.amqp.org/confluence/download/attachments/2523324/AMQP+F2F+Presentation.pdf
I don't know if these are still relevant...

Cheers,

Lionel