<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On Jul 12, 2013, at 5:27 PM, Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 5:40 PM, William Henry <span dir="ltr"><<a href="mailto:whenry@redhat.com" target="_blank">whenry@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><div>Hi all,<br></div><div><br></div>
<div>I've been reading through the Messaging Wiki and have some comments. Not criticisms, just comments and questions.<br> I have found this to be a very useful document. Thanks.<br></div><div><br></div><div>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."<br>
</div><div><br></div><div>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.<br>
</div></div></div></blockquote><div><br></div><div style="">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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><div></div><div><br></div>
<div>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?<br>
</div></div></div></blockquote><div><br></div><div style="">The latter.</div></div></div></div></div></blockquote><div><br></div>Ack. Good. Fits very well into AMQP 1.0 then ;-)<div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif">
<div></div><div><br>3. Some messaging nomenclature: The way the wiki describes RPC "<span>Invoke Method on One of Multiple Servers</span>" 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.)<br>
</div><div><br></div><div>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. <br></div><div><br></div><div>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.<span style="font-family:arial;font-size:small"> </span></div>
</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><div> <br></div>
<div><br></div><div>(BTW I've seen this kind of confusion also in early versions of MCollective in Puppet.)<br></div><div><br></div><div>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).<br>
</div></div></div></blockquote><div><br></div><div style="">Too many of these terms are overloaded. :-)</div></div></div></div></div></blockquote><div><br></div><div>Yep. But topic pup/sub is certainly different to a queue. ;-)</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style=""><br></div><div style="">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?</div></div></div></div></div></blockquote><div><br></div><div><br></div>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.<div><br></div><div>William</div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div style=""><br></div><div style="">Thanks,</div><div style="">Doug</div><div style=""><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif">
<div></div><div><br></div><div>Please feel free to respond and critique my comments/suggestions.<br></div><div><br></div><div>Best,<br></div><div>William<br></div><div><br></div><div><br></div></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OpenStack-dev mailing list</span><br><span><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></div></div></body></html>