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 <[EMAIL PROTECTED]> 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" |
| | <[EMAIL PROTECTED]|
| | il.com> |
| | |
| | 25/09/2006 23:57 |
| | Please respond to|
| | qpid-dev |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [email protected]
|
|
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 <[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.
> >
>
>
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.
