[rabbitmq-discuss] 2.0: The Future of Pika
stastny at 101ideas.cz
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.
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:
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss