On 06/22/2012 05:28 PM, Andrew Stitcher wrote:
- Allowing ":" as well as "://" in the place after the scheme adds a
potential ambiguity to the syntax. If we didn't allow it then amqp:5672
would unambiguously denote a url connecting to host called amqp and port
5672. However allowing it it would denote that or a host called 5672 and
the default port.
This might not seem like a big issue, but it limits the parser to
accepting known schemes, which is not great. It would be better for the
parser to be able to tell a scheme unambiguously from the syntax.
In general though it is the other way round, i.e. the scheme determines
the syntax.
I think the assumption you are making is that the syntax is always the
'Common Internet Scheme Syntax' of RFC 1738, and the scheme name can
then solely be used to determine aspects of the protocol(s) to use (e.g.
amqp v mqtt or amqp over tls etc).
I can certainly see advantages with that approach.
So I'd actually prefer to not allow a single ":" in this place in the
syntax except that the C++ parser and the 0-10 syntax both allow it.
[I note that as far as general uri syntax is concerned only the ":" is
strictly necessary because what follows is not hierarchical.
That was the reason the '//' was left out in the 0-10 specification,
i.e. it was based on '2.1.2 Improper use of "//" following "<scheme>:"'
in RFC 2718.
I think
this would be more significant if it we didn't break the uri syntax by
not always requiring the scheme.]
Right, a string of the form myhost:5672 is not actually a url. Accepting
strings that aren't urls (i.e. that skip the scheme) is I think again a
convention copied from browsers where http is then implied (as is the
'Common Internet Scheme Syntax').
I think we should continue with a pragmatic approach for now and accept
that there are two distinct scheme syntaxes for which a case can be made.
One is the amqp scheme as defined in the 0-10 specification. Support for
this already exists in the c++ broker, the c++ client and in a more
limited guise in the python and JMS clients, and is to an extent at
least required (since it is the standard mechanism to indicate members
of a clustered service).
The other is the common internet scheme syntax, which by virtue of its
general familiarity is probably the most intuitive. We probably also
want to continue to support strings that adhere to this syntax except
for the fact that they do not specify a scheme. I think this is probably
the form the Java/JMS client should be updated to recognise as part of
any move to a new 'connection string'.
I think we should fix the python and c++ clients to recognise ':' as the
separator between username and password. I'm neutral as to whether they
should continue to support the old (incorrect) separator as well, though
providing we make it clear in release notes etc its perhaps best to have
a clean break(?).
It might be worth splitting the c++ parser back into two pieces, one
that parses the 0-10 scheme, another that handles the common internet
scheme syntax. We can determine which to use either from context or by
treating 'amqp:' if *not* followed immediately by '//' as implying the
0-10 syntax (i.e. string starts with 'amqp:' but *not* with 'amqp://').
I think that lets each parser be simpler and less ambiguous than having
a single parser trying to cover some sort of merge of schemes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
