On Thu, 2008-01-17 at 09:05 +0000, Martin Ritchie wrote: > Rajith , > > The BindingURL was writing (as it is java) from the JMS point of view. > Hence destination is where you are publishing to in JMS. Now the > reason the wiki does not match the code is because of a problem I > realised after implementing the original spec. The URL cannot have a > '#' in the middle as this will prevent the URI class from correctly > parsing it. Hence the need to have the routing_key as an option. > > I would also be very cautious about changing this format as it is used > in a lot more places that the Java. I would suggest that if you do > wish to change the format then changing the code so that it matches > the wiki documentation would be the way to go. If you do that then a > change will be needed to update the C++ and .NET as they both use this > format to encode the replyTo field.
I think that AMQP should define the replyTo URL. If this is not already the case we should then raise this issue with the AMQP list. > Really what should happen is that the BindingURL be used solely on the > broker for parsing the bindings defined in the configuration file and > either a simplified version or a new format be decided for replyTo > encoding. We used to use Q|T+RoutingKey but that limited us in the > java to only using the built in exchanges. Perhaps a subclass of > BindingURL could be used to only present the values required to > perform a reply. To be honest we had troubles with the binding URL when trying to get the JMS code inter-operate with c++ and python samples. For doing that we needed to use the faneout exchange, to use a different binding key than the queue name and to bind a queue with more than one binding key. This reminds me some discussion we recently had on the AMQP list about how to decide whether a JMS topic exists and a way of solving that issue would be to define AMQP alias for an exchange, routing-key(s) pair. It could be a good idea to start thinking about this wider notion of AMQ destination. However the issue is that AMQP destinations are not matching the notion of JMS one. If we consider the current binding URL scheme and what people want to achieve, a destination would be defined by: an exchange name, an optional queue name, some optional binding keys and options. This has however different semantics whether we use the destination for consuming or for producing. What does that means producing a message to a destination with several binding keys? That's hard to say and I would say that it makes no sense. This is why I would suggest that we do not allow using more than one binding key unless we introduce a kind of "read only" notion. A "read only" destination would only be used for consumption. This being said, we are trying to define those binding URL schemes for writing pure JMS code that benefits from advanced AMQP features. The question may therefore be whether we wish to extend the JMS API with some officially supported new AMQPish features or if we want to ban that and assume that programmers will either use the JMS or the AMQP API? We already have extended the JMS API (see org.apache.qpid.jms) so why would we not do that for adding binding keys to a consumer? Arnaud
