Do we really need queue semantics in the Sender?

[gregturn]

I was confused when I saw Sender with methods like declareQueue(). I thought that in AMQP, queues were components of the Receiver, and that senders only talk to exchanges.

Seeing no declareQueue() methods on the Receiver, it almost sounds like the methods were put in the wrong class. This forced me to use Spring AMQP's BindingBuilder` to construct the queue and bindings for the consumer.

[acogoluegnes]

Fair enough, the semantics behind the Sender are write operations, which loosely includes any operation on resources (exchanges, bindings, and queues). One benefit is to use only one class (and a fluent API) to configure a topology and publish messages.

This remark makes me think we could introduce (in 2.0) an Admin class to deal only with resources, just like in Spring AMQP. We could still be able to use a fluent API to configure and publish, but not on the same class.

[acogoluegnes]

Another comment leaning toward removing queue semantics from the Sender.