On 06/22/2012 05:28 PM, Andrew Stitcher wrote:
I think we need to focus the URL syntax discussion on a specific
proposal with concrete syntax to be implemented.
I think we should take this in parts, and it appears to me that we have
somewhat muddies the waters by conflating the connection URL syntax and
the connection string (including whatever options) together.
For concreteness here is a proposal (it is the best most overlapping
syntax with both c++ and python syntaxes that I can think of presently):
I'm only covering a *single url* here and multiple urls will need to be
combined either in a list or in options as elsewhere discussed on the
thread.
scheme ::= "amqp" | "amqps" | "amqpr"
host ::= name | ipv4literal | "[" ipv6literal "]"
url ::= [scheme ("://" | ":")] [user ["/" password] "@"] host [":" port]
I think the 'amqp' scheme should really be specified by the OASIS AMQP
member section.
We use it currently in three ways (in order of increasing abuse!): (i)
in line with the 0-10 specifications defined scheme, (ii) a simple
scheme that (roughly) mirrors the http urls many are familiar with (i.e.
what you are proposing here[1]) and (iii) the JMS connection-url format.
We may feel we have to live with our current abuses a little longer. We
may want to make our client libraries more uniform in their abuse.
Since it essentially just documents current practice, your proposal does
not really 'expand' the abuse (except in one small way, amqpr, on which
more later). However we should be clear that it is using 'amqp' as an
identifier for an entirely non-standard scheme.
A little history...
The c++ client originally supported only (i). Support for a part -
everything but the scheme - of (ii) was then added. A scheme of amqp
taken to indicate a url of form (i) and originally the two forms were
treated separately (they were later merged and the parser for (i) was
expanded to handle that).
The reason for adding the extra support was (a) to provide more overlap
with python and (b) because it allowed simple host:port urls which were
quicker to type in running tests and felt a little more intuitive for
new users etc.
The first of these reasons could equally have been handled by added
support for (i) in the python client.
In form (ii), the only use made of the scheme is if amqps is specified,
in which case that indicates SSL/TLS should be used. This is analogous
to the familiar https v. http scheme people type in their browsers. In
passing I think 'amqpr' is stretching that analogy too far. There is no
standard way of layering AMQP on RDMA, where there is with TLS.
I agree it is handy to be able to specify a transport in the url (though
currently only the c++ client supports RDMA and it can also be simply
set as an option). I actually like the 0-10 syntax for this. I think it
should be less lenient and require the scheme *and* transport (as
specified I believe it does). I think its also reasonable to allow
host:port as a shortcut (i.e. if you don't recognise the scheme, treat
it as the host). The one thing it doesn't do is let you specify username
and password.
[1] Note also that it in (ii) should really be:
[user [":" password] "@"]
rather than
[user ["/" password] "@"]
to match http usage. I think that may have been my fault!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
