[rabbitmq-discuss] 2.0: The Future of Pika

[james anderson]

On 2011-03-13, at 18:20 , Matthias Radestock wrote:

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

any one of those.
it depends on which of its attributes have been constrained by  
assigned values.
(1) is the class' interface (as you note below). most likely an  
instance would correspond to (3) or (6), but the particulars would  
depend on the application's control patterns.

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