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 Wed, 27 Sep 2006 00:23:10 GMT
For testing I understand.
But what are we testing at that point?

You should be able to run one test harness against both the C++ and Java
servers... that would be real leverage; and that would use IP.

I think popping out the notion of a VM transport sends a bad message to
prospective users.
Does the HTTPD team test that with a loopback of sorts or the Samba team?  I
suspect not.

Just my 2c
John

On 26/09/06, Robert Greig <robert.j.greig@jpmorgan.com> wrote:
>
> The in-VM transport enables you to run a client and broker in the same
> JVM.
> This is extremely useful for testing purposes.
>
> RG
>
>
> |---------+---------------------------->
> |         |           "John O'Hara"    |
> |         |           <john.r.ohara@gma|
> |         |           il.com>          |
> |         |                            |
> |         |           25/09/2006 23:57 |
> |         |           Please respond to|
> |         |           qpid-dev         |
> |---------+---------------------------->
>
>   >------------------------------------------------------------------------------------------------------------------------------|
>
>   |                                                                                 
                                            |
>   |       To:       qpid-dev@incubator.apache.org
>                                                                                 |
>   |
> cc:                                                                                 
                                  |
>   |       Subject:  Re: Qpid URL Formats [ was Re: A question for the
> ActiveMQ chaps on the list...]                             |
>
>   >------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
> 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.
> > >
> >
> >
>
>
>
>
> 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