qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the list...]
Date Mon, 25 Sep 2006 22:57:56 GMT
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 <aconway@redhat.com> 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"    |
> > |         |           <john.r.ohara@gma|
> > |         |           il.com>          |
> > |         |                            |
> > |         |           2006-09-22 20:49 |
> > |         |           Please respond to|
> > |         |           qpid-dev         |
> > |---------+---------------------------->
> >
> >------------------------------------------------------------------------------------------------------------------------------|
> >
> |                                                                                   
                                          |
> >   |       To:       qpid-dev@incubator.apache.org
>                                                                                 |
> >   |
> 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 <hiram@hiramchirino.com> wrote:
> > >
> > > On 9/22/06, Gordon Sim <gsim@redhat.com> wrote:
> > > > James Strachan wrote:
> > > > > On 9/22/06, John O'Hara <john.r.ohara@gmail.com> 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.
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message