On 06/22/2012 08:47 PM, Andrew Stitcher wrote:
On Fri, 2012-06-22 at 20:10 +0100, Gordon Sim wrote:
...
I think the 'amqp' scheme should really be specified by the OASIS AMQP
member section.
I entirely agree with this, but in the meantime it will help qpid a lot
to use the same connection url means.
...
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.
I think this is my position although I'm not clear that there is
actually any abuse going on - but that is entirely subjective.
Since we both agree that a scheme identified as 'amqp' should properly
be defined by (or at least in conjunction with) those in charge of the
AMQP specification, using 'amqp' as an identifier for ad-hoc schemes is
not really legitimate.
We have done so for two different scheme definitions (the AMQP WG
additionally, and legitimately, defined a third). The fact that abuse of
the amqp scheme identifier has occurred seems inescapable to me, however
negligible the consequences are felt to be.
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...
...
This is very informative, but I was hoping to receive comments on the
specific proposal.
You did receive comments, the most important of which was that the
scheme you document (one of three schemes for which there is some
support in the project) is not defined by the AMQP standards group
despite its name.
Perhaps a counter proposal even. I'm not clear if you
are saying:
1) Leave things as they are, there's not a real problem here.
There is a problem. More than one in fact. One is that the JMS
connection URL is not easy or pleasant to work with. Another is the lack
of uniformity between client libraries in the different languages
(particular those implementing the messaging API). The ambiguity in the
c++ parser may be another. Yet another is that we have used 'amqp' to
denote two Qpid specific schemes in addition to the scheme defined in
the 0-10 specification, though that is 'spilt milk' at this stage.
2) Wait until the OASIS AMQP group specifies something.
If the OASIS AMQP group define another url scheme we should add support
for it. Until then we should certainly avoid making up any further
'amqp' schemes.
The AMQP WG (before they moved to OASIS) did of course already define an
'amqp' scheme (though it is not registered with the IETF) in the 0-10
specification.
3) This proposal is rubbish, do ....
4) This proposal needs modifying in this way ... because...
5) Something else
The scope of your proposal was not made explicit. For clarity, are you
proposing:
(a) that the scheme you documented by adopted as *the* Qpid url scheme,
with support for all other schemes (including that defined in the 0-10
specification) being deprecated or removed?
or
(b) that we simply expand the support for the scheme you documented
without removing support for other formats?
If (a), I quite like the 0-10 scheme and it does have the advantage of
actually being specified by the AMQP WG.
The main criticisms of it seem to be that it is a little verbose for the
simple cases and that it doesn't allow you to specify username and
password, neither of which seems particularly devastating to me.
I would rather wait for the custodians of AMQP to themselves deprecate
the scheme in favour of something else.
If (b) I think that just means adding support to the JMS client and
potentially adding amqps as a scheme the c++ client recognises as
implying SSL. I am not in favour of recognising the 'amqpr' scheme as
implying AMQP over Qpid's RDMA transport.
I'm not trying to put words in your mouth, I'd just like to progress
this discussion towards some conclusion.
[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!
My proposal didn't seek to match http really, rather unify what was
there.
Right, but what is there is there in general because it sought to match
http. That is the only reason I don't reject that unofficial form
entirely: it is at least somewhat logical to anyone familiar with http
urls (which I think is pretty much every potential user of Qpid).
Because of the clear lack of syntactic ambiguity I actually
prefer using "/" as a separator.
I would prefer using ':' to match http as I think that will be more
intuitive to users.
Although there may be no technical syntactic ambiguity with ":" in this
place (as it must be followed by "@" to mean following password) I think
you will need to backtrack to reinterpret a ":" already seen if you then
see a "@".
In the same way I'd suggest that if we include the transport protocol in
the address part then we use a different separator than ":" as I like
the convenience of leaving parts out. "%" is unused so far - mayber we
can invent a use for all the standard graphical characters :)
>
So I'm implying something like "amqp://user/password@ssl%host:port"
which does actually look really horrible.
I'm not in favour of further augmenting the non-standard 'amqp' scheme
we have adopted as the sole purpose of introducing that scheme was its
mirroring of commonly understood aspects of the http/https url schemes.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
