On 18/01/2008, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > 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.
>From what I've been told it does in 0-10 > > 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. Then that is mainly a failing of client.AMQQueue not the BindingURL. It would already return the routingKey if the exchange was amq.direct, which in the fanout case it isn't > 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. I would have said that a destination with several binding keys is just a short hand notation for requesting multiple deliveries of the message. Compare to SMTP (as AMQP is fond to do) multiple routingkeys on a publish is simply many addresses in the To: field. > 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? There should never be a question of using interfaces A or interfaces B that will never work. In Java JMS _IS_ the interfaces used, the only option is to extend it but that should only be for the 1% use cases. Vendor lockin is something AMQP is working to avoid. So in the Java space we should attempt to be pure JMS. The AMQP features can be worked in via config such as JNDI or broker side queue configurations. > Arnaud -- Martin Ritchie
