Hi, > -----Original Message----- > From: David Greaves [mailto:[email protected]] > Sent: Monday, October 31, 2011 1:34 PM > To: Ed Bartosh > Cc: [email protected]; [email protected] > Subject: Re: [Meego-distribution-tools] ruote-amqp-pyclient crashes > when declaring exchange > > I was at LinuxCon all last week so things were delayed :) > > On 18/10/11 08:33, Ed Bartosh wrote: > >> (Although I suspect it won't work if you run a participant against a > new > >> rabbit server without running BOSS first - a really minor issue.) > > Why do you think so? Can you elaborate a bit? > > When I said 'new' I meant a fresh install, not latest version. > > Because (for early AMQP servers at least) the exchange and queue > binding won't > exist until either BOSS or the client creates them. It's not really a > big deal > since I suspect most users will install rabbit as part of the BOSS > install > anyway. It was also good practice for a time (coming soon) when the > exchange and > binding were not to the pre-existing default exchange. > > >> Looking at the second patch then. > >> > >> The objective for ruote-amqp-pyclient (being renamed and packaged as > >> python-ruote-amqp) > > Where can I see its git repo? Does this mean that ruote-amqp-pyclient > is > > going to be dropped or renamed on gitorious? > > It's still at > https://meego.gitorious.org/meego-infrastructure-tools/ruote-amqp- > pyclient > I was just noting the 2 names as it can be confusing. It was an > unfortunate choice of repo name when I first made it. > Ah, OK. Now I understood that. It's the same project, but its name differs from package name. > >> The reason ruote uses queue=routing_key is that AMQP is being used > purely > >> to deliver direct messages to a single queue shared by all > participants. A > >> ruote message *must not* be consumed by more than one participant. > >> > > That's perfectly understood. However, it doesn't contradict with > possibility > > to have routing_key!=queue. > > > >> Of course I could be missing something : can you provide an example > where 2 > >> participants would bind the same queue with different keys? > >> > > Correct me if I'm wrong, but it looks like you're confusing two > different > > things here. Having routing_key != queue doesn't mean that there have > to be > > two participants binding to the same queue with different keys. It > only means > > that it's possible to have queue != routing key even for the single > > participant. As soon as queue and routing key are different matters > they can > > potentially be different. > > I certainly could be wrong. > > The 'process definition' has lines which may mention a 'participant > name'. > Ruote maps that via the lookup table to an AMQP proxy which specifies a > 'queue' > (Typically the 'queue' matches the 'participant name' but we have > advanced use > cases around dynamically generated names and ruote's "listen" directive > where we > have queue != participant name (although with newer ruote even that > case could > probably be deprecated) > > This is sent as an amqp message to a specific exchange. The message has > a > 'routing key'. The 'routing key' is the same as the 'queue'. > > Providing options like this makes for confusion; eg: > The "notify" statement uses the "notifications" queue which is > addressed by the > "notification" key and goes to the "emails" participant... > cf > The "notify" statement uses the "notify" queue which is addressed by > the > "notify" key and goes to the "notify" participant... > > So .. until there's a use-case for the former complexity I think we > should use > routing key == queue > Got it. It's route-specific restriction. In this case it makes much more sense to decouple ruote from boss plugin. (See my previous mail).
Regards, Ed _______________________________________________ MeeGo-distribution-tools mailing list [email protected] http://lists.meego.com/listinfo/meego-distribution-tools
