On 08/01/07, Alan Conway <[EMAIL PROTECTED]> wrote:
On Mon, 2007-01-08 at 06:33 -0800, [EMAIL PROTECTED] wrote:
> Page Edited : qpid : BindingURLFormat BindingURLFormat has been edited
> by Martin Ritchie (Jan 08, 2007).
>
> (View changes)
>
> Content:
> <Exchange Class>://<Exchange
Name>/[<Queue>][?<option>='<value>'[&<option>='<value>']]
>
snip
> Examples
> direct://amq.direct/SimpleQueue
> direct://amq.direct/UnusuallyBoundQueue?routingkey='queue'
> topic://amq.topic?routingkey='stocks.#'
> topic://amq.topic?routingkey='stocks.nyse.ibm'
Using exchange types as the protocol prefix of a URL is a bad idea, you
would never be able to standardize it with IANA or whoever monitors
these things. The set of exchange types is open to change in the future
but URL protocol prefixes must be unique forever.
Also this format abuses the prefix://host/path convention for internet
protocols.
This isn't an Internet protocol URL it just looks like one. This is a
BindingURL for binding a Destination(Queue/Topic/Header) to a routing
key. IANA should have nothing to say about it. The AMQP WG do need to
define this for interop.
IANA would need to agree the ConnectionURL as described on this page
(http://cwiki.apache.org/confluence/display/qpid/ConnectionURLFormat)
which does start amqp:// and is used for performing connections as an
Internet protocol. Although it too does abuse to format of
prefix://host/path as AMQP connections are not constrained to a single
host.
amqp://[<user>:<pass>@][<clientid>]<virtualhost>[?<option>='<value>'[&<option>='<value>']]
As you can see the 'host' value is the client_id.
Other suggestions are welcome. We have these two url formats in
production use where we need to specify multiple hosts for failover.
One approach would be to put the 'first' broker as the host:port and
the rest as parameters but this just seems wrong as you are some how
saying one broker is more important than the others.
I'd suggest something like:
qpid://<host>[:<port>]/<exch class>:<exch name>/[etc. as above]
Long term we'll want vendor neutral standard AMQP URLs like:
amqp:...
But it would be a mistake to try to grab the amqp: prefix right away.
That would make transition to standard AMQP URL's *more* difficult in
the future because we'd have no easy way to distinguish between an AMQP
standard URL and an old qpid-proprietary URL for backwards
compatibility.
Cheers,
Alan.
--
Martin Ritchie
