<div><div><span><div><div><div>
<div>
<span>
<br>
</span>
<span></span>
<p style="color: #a0a0a0;">On Sunday, March 13, 2011 at 1:20 PM, Matthias Radestock wrote:</p><blockquote type="cite"><div>
<span><div><div>Gavin,<br><br>Gavin M. Roy wrote:<br><blockquote type="cite"><div>The major change for the driver, from my perspective, is the removal of <br>auto-generated driver mixin rpc command methods to having a object model <br>closer to what is seen in spec.py, with the AMQP methods accessed <br>through their class directly. Think Basic.ack(channel, delivery_tag) <br>instead of channel.basic_ack(delivery_tag).<br></div></blockquote><br>It's a common misconception about AMQP that the spec's class/method <br>terminology implies some sort of sensible mapping to the corresponding <br>OO terms. It does not.</div></div></span></div></blockquote><div>Right, I am familiar with the differences.</div><blockquote type="cite"><div><span><div><div><span></span>What state is associated with instances of the Basic class?</div></div></span></div></blockquote><div>In what I am proposing to change, there would be no state for Basic class. </div><blockquote type="cite"><div><span><div><div><span></span>Or with instances of the Queue class?<br><br>6) A queue of a specific name, in a particular vhost & broker</div></div></span></div></blockquote><div>More specifically a queue of a specific name on a specific channel.</div><blockquote type="cite"><div><span><div><div>(6) would make some sense too. The Queue constructor would take the <br>channel and queue name.</div></div></span></div></blockquote><div>*nod*</div><div><br></div><div>I want to reduce the work involved for the developer in areas where we can denote some level of state.</div><div><br></div><div>This is obviously a big change from the current client which is one of the reasons I raise the concept here.</div><div><br></div><div>Regards,</div><div><br></div><div>Gavin</div>
</div>
</div></div></div></span></div></div>