[rabbitmq-discuss] 2.0: The Future of Pika

[Matthias Radestock]

Gavin,

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

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.


Regards,

Matthias.