The URL format involves nested single quoted strings. How on earth do you parse that?
If nested values are needed then I thing some sort of bracket character is in order, but it begs the question are we trying to stuff too much info into a URL here? On Mon, 2006-09-25 at 10:02 +0100, Martin Ritchie wrote: > We currently have a URI format that is in use in the Java implementation. > > I have created a wiki page that describes this format. > > http://wiki.apache.org/qpid/URLFormats > > Comments and feedback would be great. If we can come to an agreement on the > format then we can suggest it to the AMQP WG as they do not currently have > a defined format. Such a format will be required for interoperability. > > -- > Martin > > > > > |---------+----------------------------> > | | "John O'Hara" | > | | <[EMAIL PROTECTED]| > | | il.com> | > | | | > | | 2006-09-22 20:49 | > | | Please respond to| > | | qpid-dev | > |---------+----------------------------> > > >------------------------------------------------------------------------------------------------------------------------------| > | > | > | To: [email protected] > | > | cc: > | > | Subject: Re: A question for the ActiveMQ chaps on the list... > | > > >------------------------------------------------------------------------------------------------------------------------------| > > > > > So basically we could use a URI which defines the exchanges, bindings and > queues. > A bit nasty, but there is something attractive about it in the same way > ODBC > connection strings undeniably work :-) > > John > > On 22/09/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > > > On 9/22/06, Gordon Sim <[EMAIL PROTECTED]> wrote: > > > James Strachan wrote: > > > > On 9/22/06, John O'Hara <[EMAIL PROTECTED]> wrote: > > > >> When James spent some time with us back on the early early days of > > the > > > >> AMQP I got the impression that he held the view that you could plug > > the > > > >> command verbs onto ActiveMQ and it would just work. > > > > > > > > Assuming there is indeed a well defined mapping of AMQP commands to > > > > JMS/MQSeries semantics then yes it should. > > > > > > I think a well defined mapping of JMS semantics onto AMQP commands is > > > possible and desirable. I'm not as sure that there is a mapping of AMQP > > > commands onto JMS semantics. > > > > > > For example, in AMQP there is a bind command for attaching a queue to > an > > > exchange. What concept in JMS would this command be mapped onto? > > > > > > > All the binding information can be contained in the destination name. > > > > > I'm certainly not saying that a given JMS broker could not be made to > > > support AMQP. Individual implementations may well have the necessary > > > concepts in which to express AMQP semantics, but as far as I can JMS as > > > a specification does not so I'm not clear how a generic mapping would > be > > > specified. > > > > > > > > > > > > -- > > Regards, > > Hiram > > > > Blog: http://hiramchirino.com > > > > > > > This communication is for informational purposes only. It is not intended as > an offer or solicitation for the purchase or sale of any financial instrument > or as an official confirmation of any transaction. All market prices, data > and other information are not warranted as to completeness or accuracy and > are subject to change without notice. Any comments or statements made herein > do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries > and affiliates. > > This transmission may contain information that is privileged, confidential, > legally privileged, and/or exempt from disclosure under applicable law. If > you are not the intended recipient, you are hereby notified that any > disclosure, copying, distribution, or use of the information contained herein > (including any reliance thereon) is STRICTLY PROHIBITED. Although this > transmission and any attachments are believed to be free of any virus or > other defect that might affect any computer system into which it is received > and opened, it is the responsibility of the recipient to ensure that it is > virus free and no responsibility is accepted by JPMorgan Chase & Co., its > subsidiaries and affiliates, as applicable, for any loss or damage arising in > any way from its use. If you received this transmission in error, please > immediately contact the sender and destroy the material in its entirety, > whether in electronic or hard copy format. Thank you. >
