Thanks for the feedback, this is the type of conversation I need to have as I'm fleshing things out.<br><br><div class="gmail_quote">On Sun, Mar 13, 2011 at 6:30 AM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com">matthias@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br></div>
What do instances of classes represent? Looks like they'd have to contain a mixture of attributes with completely different purposes.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div>�� � message_count, consumer_count = queue.declare(channel)</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> In particular there is a conflation of attributes for AMQP entities and AMQP commands.<br>
</blockquote><div><br></div><div>That was the initial thought, where it adds value. Where it confuses, it should not be done.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
For example, 'passive' is not an attribute of an AMQP queue; it's a flag on the queue.declare command.</blockquote><div><br></div><div>Right, in this case, it's probably better to pass that as an argument in the method call.</div>
<div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> And 'message_count' is only something you get as a return of queue.declare, so accessing that attribute in any other context is meaningless.<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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).</div>
</div>