I agree with Rajith and Gordon here - the current URLs do not seem to
follow common conventions, and are hard to remember because of that.
I don't think that Qpid has the right to register an amqp name scheme
for URLs, we have the right to use a qpid name scheme. I'm not sure
which group should create the URL format. (OK, I'm a standards geek,
it's a curse I live with ;->)
I suggest we use the conventions discussed in
http://tools.ietf.org/html/rfc3986. As I interpret it, AMQP can use any
of the following forms:
1. amqp://[EMAIL PROTECTED]/virtualhost?param=value,param=value
2. amqp://localhost/virtualhost?user=jrobie,param=value
3. amqp:localhost?virtualhost=hostname,user=jrobie
Qpid would need to use a qpid name scheme:
1. qpid://[EMAIL PROTECTED]/virtualhost?param=value,param=value
2. qpid://localhost/virtualhost?user=jrobie,param=value
3. qpid:localhost?virtualhost=hostname,user=jrobie
I prefer form 2:
"amqp" ":" "//" <authority>("/" <virtualhost>)? ("?" <parameter> "="
<value> ("," <parameter> "=" <value>)*)?
Here are the design parameters.
The name scheme is "ampq" or "qpid", depending on which group defines it.
A virtual host is a legitimate form of one-level hierarchy, so we can
use the hierarchical scheme if we so choose, and I think that's more
user friendly, especially since / is a better delimiter in URLs where :
is used for other things such as ipv6 address delimiters.
Our authority is <host>:<port>?, or possibly <username>@<host>:<port>?
Including the user's password in a URL is deprecated, so a URL like
"amqp://guest:[EMAIL PROTECTED]/virtualhost?brokerlist='localhost' " should
not be used. The user's name can occur either here, before an @, or as a
parameter in the query component.
Non-hierarchical data such as parameters belongs in the query component.
The user name could be put either here or in the authority component.
Jonathan
P.S., I personally prefer form 2 in my examples above.
Rajith Attapattu wrote:
I totally agree with Gordon here.
Most url start with <protocol>://<host>:<port>?<params>
And we seem to differ from the norm which makes it harder to remember.
Also having a brokerlist will be redundent when we introduce a
solution for
https://wiki.108.redhat.com/jira/browse/AMQP-95
The JIRA talks about a broker informing clients about possible
candidates to
use in the event a failover happens. This list is handed over when the
client connects to the broker. (Thanks Rafi for pointing this out)
Also if you use a smart cluster which does transparent failover, then the
client only needs to use a single url.
When AMQP-95 gets voted in the above URL scheme will need to change as
the
additonal information is not needed.
Regards,
Rajith
On 7/26/07, Gordon Sim <[EMAIL PROTECTED]> wrote:
Martin Ritchie wrote:
> Is this url really too difficult for your users to understand?
>
> amqp://guest:[EMAIL PROTECTED]/virtualhost?brokerlist='localhost'
Personally I find that syntax a little odd and unintuitive; it seems to
emphasise what I would consider secondary values over what I would
consider the more important and generally relevant ones.
My mind is accustomed to the host and port being in the first part of a
URL, rather than appended as query string parameters. This example
doesn't fit into any pattern I'm familiar with which makes it harder to
remember and takes more effort to parse it in my head.
That doesn't mean its wrong of course, but since the topic came up I
thought I'd toss my 2 cents in(!).
