[rabbitmq-discuss] 2.0: The Future of Pika
matthias at rabbitmq.com
Sun Mar 13 17:20:52 GMT 2011
Gavin M. Roy wrote:
> The major change for the driver, from my perspective, is the removal of
> auto-generated driver mixin rpc command methods to having a object model
> closer to what is seen in spec.py, with the AMQP methods accessed
> through their class directly. Think Basic.ack(channel, delivery_tag)
> instead of channel.basic_ack(delivery_tag).
It's a common misconception about AMQP that the spec's class/method
terminology implies some sort of sensible mapping to the corresponding
OO terms. It does not.
What state is associated with instances of the Basic class?
Or with instances of the Queue class?
When I have an instance of Queue in your proposed API, what does it
1) All queues of any name, in any vhost, in any broker
2) All queues of any name, in any vhost, in a particular broker
3) All queues of any name, in a particular vhost & broker
4) A queue of a specific name, in any vhost, in any broker
5) A queue of a specific name, in any vhost, in a particular broker
6) A queue of a specific name, in a particular vhost & broker
To me only (1) makes sense, which leaves instances stateless, so all you
are really doing is grouping a whole bunch of "static" methods under
different headings ("queue", "exchange", etc).
(6) would make some sense too. The Queue constructor would take the
channel and queue name.
More information about the rabbitmq-discuss