----- Original Message ----- > On Fri, Jul 12, 2013 at 8:09 PM, William Henry < whe...@redhat.com > wrote:
> > Sent from my iPhone > > > On Jul 12, 2013, at 5:27 PM, Doug Hellmann < doug.hellm...@dreamhost.com > > > wrote: > > > > On Fri, Jul 12, 2013 at 5:40 PM, William Henry < whe...@redhat.com > > > > wrote: > > > > > > > Hi all, > > > > > > > > > > I've been reading through the Messaging Wiki and have some comments. > > > > Not > > > > criticisms, just comments and questions. > > > > > > > > > > I have found this to be a very useful document. Thanks. > > > > > > > > > > 1. "There are multiple backend transport drivers which implement the > > > > API > > > > semantics using different messaging systems - e.g. RabbitMQ, Qpid, > > > > ZeroMQ. > > > > While both sides of a connection must use the same transport driver > > > > configured in the same way, the API avoids exposing details of > > > > transports > > > > so > > > > that code written using one transport should work with any other > > > > transport." > > > > > > > > > > The good news for AMQP 1.0 users is that technically "boths sides of > > > > the > > > > connection" do not have to use same transport driver. In pre-AMQP 1.0 > > > > days > > > > this was the case. But today interoperability between AMQP 1.0 > > > > implementations has been demonstrated. > > > > > > > > > In this case I think we mean the Transport driver from within Oslo. So > > > you > > > could not connect a ZMQ Transport on one end to an AMQP Transport on the > > > other. It will be an implementation detail of the AMQP Transport class to > > > decide whether it supports more than one version of AMQP, or if the > > > different versions are implemented as different Transports. > > > > > > > 2. I notice under the RPC concepts section that you mention Exchanges > > > > as > > > > a > > > > container in which topics are scoped. Is this exchange a pre AMQP 1.0 > > > > artifact or just a general term for oslo.messaging that is loosely > > > > based > > > > on > > > > the pre-AMQP 1.0 artifact called an Exchange? i.e. are you assuming > > > > that > > > > messaging implementations have something called an exchange? Or do you > > > > mean > > > > that messaging implementations can scope a topic and in oslo we call > > > > that > > > > scoping an exchange? > > > > > > > > > The latter. > > > > > Ack. Good. Fits very well into AMQP 1.0 then ;-) > > > > > 3. Some messaging nomenclature: The way the wiki describes RPC " Invoke > > > > Method on One of Multiple Servers " is more like a queue than a topic. > > > > In > > > > messaging a queue is something that multiple consumers can attach to > > > > and > > > > one > > > > of them gets and services a message/request. A topic is where 1+ > > > > consumers > > > > are "connected" and each receives a the message and each can service it > > > > as > > > > it sees fit. In pre-AMQP 1.0 terms what this seems to describe is a > > > > direct > > > > exchange. And a direct excahnge can have multiple consumers listening > > > > to > > > > a > > > > queue on that exchange. (Remember that fanout is just a generalization > > > > of > > > > topic in that all consumers get all fanout messages - there are no > > > > sub-topics etc.) > > > > > > > > > > In AMQP 1.0 the addressing doesn't care or know about exchanges but it > > > > can > > > > support this queue type behavior on an address or topic type behavior > > > > on > > > > an > > > > address. > > > > > > > > > > I know this isn't about AMQP specifically but therefore this is even > > > > more > > > > important. Topics are pub/sub with multiple consumer/services > > > > responding > > > > to > > > > a single message. Queues are next consumer up gets the next message. > > > > > > > > > > (BTW I've seen this kind of confusion also in early versions of > > > > MCollective > > > > in Puppet.) > > > > > > > > > > It might be better to change some of the references to "topic" to > > > > "address". > > > > This would solve the problem. i.e. a use case where one of many servers > > > > listening on an address services a message/request. And later all of > > > > servers > > > > listening on an address service a message/request. Addressing also > > > > solves > > > > the one-to-one as the address is specific to the server (and the others > > > > don't have to receive and reject the message). > > > > > > > > > Too many of these terms are overloaded. :-) > > > > > Yep. But topic pup/sub is certainly different to a queue. ;-) > > > > I'm not sure of the details of how "topic" and "address" are different in > > > AMQP 1.0. The word "address" implies to me that the message sender knows > > > where the message receiver is in some concrete sense. We don't want those > > > semantics in a lot of our use cases. If the "address" is abstract, then > > > it > > > sounds like it works much as a topic does. Maybe you can expand on the > > > differences? > > > > > Nope the address is essentially a namespace. The send knows not where it > > ends > > up. Hence in some applications it doesn't even know of its a topic or a > > queue an it could go to one or many depending. > > OK, that sounds like it would be part of the Transport's handling of a Target > ( > https://github.com/markmc/oslo.messaging/blob/master/oslo/messaging/target.py > ). Thanks Doug. This is interesting. What's the difference between an exchange and a namespace? If exchange is a scope and namespace is essentially a scope, then why have both? William > Doug > > William > > > > Thanks, > > > > > > Doug > > > > > > > Please feel free to respond and critique my comments/suggestions. > > > > > > > > > > Best, > > > > > > > > > > William > > > > > > > > > > _______________________________________________ > > > > > > > > > > OpenStack-dev mailing list > > > > > > > > > > OpenStack-dev@lists.openstack.org > > > > > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > _______________________________________________ > > > > > > OpenStack-dev mailing list > > > > > > OpenStack-dev@lists.openstack.org > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > > > OpenStack-dev mailing list > > > OpenStack-dev@lists.openstack.org > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
