Also, what's this VM transport in the suggested URL scheme!!!!
I don't think that's terribly portable.... how about we stick to TCP until its all working. Same as NFS, HTTP etc. they are socket bound. Theres is also the SSL discussion, whether to negotiate on the same port, or use a different port. The W3C standard on URI's would suggest this is a more correct representation of either approach: amqp:// amqp+tls:// <- recommended way of adding transport optionality amqps:// <- no choice, essentially a different protocol Looks like its going to be an interesting session in Boston! Cheers John On 25/09/06, Alan Conway <[EMAIL PROTECTED]> wrote:
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. >
