[rabbitmq-discuss] 2.0: The Future of Pika

Mon Mar 14 11:43:10 GMT 2011

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.

Jakub

http://www.flickr.com/photos/jakub-stastny
http://twitter.com/botanicus

On 14 March 2011 10:27, Marek Majkowski <majek04 at gmail.com> wrote:

> On Sat, Mar 12, 2011 at 23:12, Gavin M. Roy <gmr at myyearbook.com> wrote:
> [...]
> > The basic sentiment I've picked up on is that
> > Callback Passing Style (CPS) is not currently in favor in the Python
> > community.
>
> It never has been. That's why Twisted is still perceived as a separate
> library (as opposed to, for example EventMachine for ruby, which
> often is treated as a core part of the ruby framework).
>
> > The roadmap for changes to Pika 2.0:
> [...]
> > - Remove existing connection adapter system
> > - Implement new pattern for use, behavior based use focused on
> > both Asynchronous callback passing style and "Pythonic" development.
> >   - Both behaviors available from the same API calling same classes and
> > methods
> >   - Async:
> >     - Merge existing connections into one connection system with IOLoop
> > override
> >       - Supporting internal IOLoop, tornado, twisted
> >   - Pythonic:
> >     - high-level blocking on synchronous AMQP commands
> >     - Generator for receiving messages from Basic.Publish
>
> That's a quite interesting approach. But non-trivial python
> generators are hard to compose. Beware.
>
> > - API notation closer to AMQP spec for implementation.
>
> Sounds good.
>
> > - *.*Ok frames will only be passed back in CPS use.
>
> That means using 'no-wait' whenever possible.
> But what if the thing will crash a channel
> (trigger an amqp channel-error). How would you notify
> a user that the channel can't be used any more?
>
> For example: queue.unbind() with bad parameters may
> trigger a channel-wide NotFound error.
>
> [...]
> > I am looking for feedback on this direction. Do these changes and the
> > example make sense to existing Pika and RabbitMQ uses?  Would you change
> > anything about this direction? What would you improve?
>
> You may find this inspiring:
> https://github.com/ask/kombu/blob/master/examples/complete_receive.py#L39
> https://github.com/majek/puka/blob/master/examples/stress_amqp.py#L60-62
>
> Cheers,
>  Marek
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110314/87d33bca/attachment.htm>