Open Stack

On 10/12/13 12:15 +0000, Gordon Sim wrote:
>On 12/09/2013 11:29 PM, Mark McLoughlin wrote:
>>On Mon, 2013-12-09 at 16:05 +0100, Flavio Percoco wrote:
>>Sounds sane to me.
>>
>>To put it another way, assuming all AMQP 1.0 client libraries are equal,
>>all the operator cares about is that we have a driver that connect into
>>whatever AMQP 1.0 messaging topology they want to use.
>>
>>Of course, not all client libraries will be equal, so if we don't offer
>>the choice of library/driver to the operator, then the onus is on us to
>>pick the best client library for this driver.
>
>That is a fair point. One thing to point out about Qpid proton is that 
>it is in fact two different things in the one library. On the one hand 
>it is a fully fledged client library with its own IO and model of use. 
>On the other hand it has a passive protocol engine that is agnostic as 
>to the IO/threading approach used and merely encapsulates the encoding 
>and protocol rules. This allows it to be integrated into different 
>environments without imposing architectural restrictions.
>
>My suggestion would be to use the protocol engine, and design the IO 
>and threading to work well with the rest of the oslo.messaging code 
>(e.g. with eventlet or asynchio or whatever). In some ways this makes 
>oslo.messaging a client library in its own right, with and RPC and 
>notify based API and ensuring that other choices fit in well with the 
>overall codebase.
>

This is very interesting and fits perfectly with oslo.messaging
executors. Assuming we'll use proton, I imagine we'll have a simple
implementation for a tcp transport that we could use with
oslo.messaging executors to get and send messages.

Cheers,
FF

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131210/5066342a/attachment.pgp>