Just a technical note about Ruby and EventMachine, I would not say it's treated as a core part of the ruby framework. There are some libraries (not many though) which are EventMachine-only, like current AMQP gem, but it's just because it's hard to write library which can run asynchronously with EventMachine a well as synchronously without it. So it's probably the same as in Python with Twisted, I guess.<div>
<br clear="all">Jakub<div><div><br></div><div><a href="http://www.flickr.com/photos/jakub-stastny/" target="_blank">http://www.flickr.com/photos/jakub-stastny</a></div></div><div><a href="http://twitter.com/botanicus" target="_blank">http://twitter.com/botanicus</a></div>
<br>
<br><br><div class="gmail_quote">On 14 March 2011 10:27, Marek Majkowski <span dir="ltr"><<a href="mailto:majek04@gmail.com">majek04@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Sat, Mar 12, 2011 at 23:12, Gavin M. Roy <<a href="mailto:gmr@myyearbook.com">gmr@myyearbook.com</a>> wrote:<br>
[...]<br>
<div class="im">> The basic sentiment I've picked up on is that<br>
> Callback Passing Style (CPS) is not currently in favor in the Python<br>
> community.<br>
<br>
</div>It never has been. That's why Twisted is still perceived as a separate<br>
library (as opposed to, for example EventMachine for ruby, which<br>
often is treated as a core part of the ruby framework).<br>
<div class="im"><br>
> The roadmap for changes to Pika 2.0:<br>
</div>[...]<br>
<div class="im">> - Remove existing connection adapter system<br>
> - Implement new pattern for use, behavior based use focused on<br>
> both Asynchronous callback passing style and "Pythonic" development.<br>
> - Both behaviors available from the same API calling same classes and<br>
> methods<br>
> - Async:<br>
> - Merge existing connections into one connection system with IOLoop<br>
> override<br>
> - Supporting internal IOLoop, tornado, twisted<br>
> - Pythonic:<br>
> - high-level blocking on synchronous AMQP commands<br>
> - Generator for receiving messages from Basic.Publish<br>
<br>
</div>That's a quite interesting approach. But non-trivial python<br>
generators are hard to compose. Beware.<br>
<div class="im"><br>
> - API notation closer to AMQP spec for implementation.<br>
<br>
</div>Sounds good.<br>
<div class="im"><br>
> - *.*Ok frames will only be passed back in CPS use.<br>
<br>
</div>That means using 'no-wait' whenever possible.<br>
But what if the thing will crash a channel<br>
(trigger an amqp channel-error). How would you notify<br>
a user that the channel can't be used any more?<br>
<br>
For example: queue.unbind() with bad parameters may<br>
trigger a channel-wide NotFound error.<br>
<br>
[...]<br>
<div class="im">> I am looking for feedback on this direction. Do these changes and the<br>
> example make sense to existing Pika and RabbitMQ uses? Would you change<br>
> anything about this direction? What would you improve?<br>
<br>
</div>You may find this inspiring:<br>
<a href="https://github.com/ask/kombu/blob/master/examples/complete_receive.py#L39" target="_blank">https://github.com/ask/kombu/blob/master/examples/complete_receive.py#L39</a><br>
<a href="https://github.com/majek/puka/blob/master/examples/stress_amqp.py#L60-62" target="_blank">https://github.com/majek/puka/blob/master/examples/stress_amqp.py#L60-62</a><br>
<br>
Cheers,<br>
<font color="#888888"> Marek<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div>