[rabbitmq-discuss] 2.0: The Future of Pika

[Marek Majkowski]

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