qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the list...]
Date Mon, 25 Sep 2006 14:45:52 GMT
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
View raw message