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
pgpmV4nRbEhH1.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
