[rabbitmq-discuss] 2.0: The Future of Pika

Gavin M. Roy gmr at myyearbook.com
Sun Mar 13 16:25:58 GMT 2011


Thanks for the feedback, this is the type of conversation I need to have as
I'm fleshing things out.

On Sun, Mar 13, 2011 at 6:30 AM, Matthias Radestock
<matthias at rabbitmq.com>wrote:

>
> What do instances of classes represent? Looks like they'd have to contain a
> mixture of attributes with completely different purposes.


Quite possibly, again the goal being simplification and making it more
pythonic. If you have a Queue (within Rabbit and in a general sense),
message-count and consumer-count are of course transient, but they are still
an attribute of a queue.

The problem with this notion is the transient nature of the values. They
are potentially invalid as soon as they are returned. Perhaps, while keeping
a more pythonic idiom in mind, it might be better for synchronous command
response syntax to be like:

     message_count, consumer_count = queue.declare(channel)


> In particular there is a conflation of attributes for AMQP entities and
> AMQP commands.
>

That was the initial thought, where it adds value. Where it confuses, it
should not be done.

For example, 'passive' is not an attribute of an AMQP queue; it's a flag on
> the queue.declare command.


Right, in this case, it's probably better to pass that as an argument in the
method call.


> And 'message_count' is only something you get as a return of queue.declare,
> so accessing that attribute in any other context is meaningless.
>

Per my point on this above, I absolutely agree here. I'm trying to walk a
line of simplification while staying true to the protocol. I there there is
a win in simplification, for example, in the aggregation of content from the
multiple frames of Basic.Deliver and Basic.GetOk. I don't think a developer
will be shorted in having one object containing all of the values of the
three frames.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110313/d9dca00c/attachment.htm>


More information about the rabbitmq-discuss mailing list