On 06/25/2012 07:51 PM, Andrew Stitcher wrote:
On Mon, 2012-06-25 at 13:14 +0100, Gordon Sim wrote:
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.
Ah finally I understand this point, sorry to be so dense.
* Your objection is that using the "amqp" scheme name for a syntax not
sanctioned by the AMQP working group. *
Yes. In fact we are using it to identify *two* different syntaxes,
neither of which is sanctioned by the AMQP working group. Which is why I
am keen that we don't do anything that could appear to be adding a third
such definition.
I agree this is a problem.
Actually I'd personally be entirely happy in this context to use "qpid"
etc. or similar as a scheme name instead (to be used in the proposed
unified scheme, with perhaps "amqp" as a back compatible alternative)
In fact it seems to me that proving a url format in the context of qpid
or some other amqp implementation makes good sense before specifying
something into the amqp spec itself
---
I agree with the desire not to expand the scheme to amqps, amqpr etc. As
another suggestion I quite like using + to separate subordinate parts of
the scheme like this "amqp+ssl", "amqp+rdma" - this is used in a few
schemes although I'm not sure about whether "+" used like this has an
official meaning.
I do prefer that convention, it seems much clearer.
This could be "qpid+.." if we don't appropriate the
amqp scheme name.
---
As I mentioned there is a definition in the 0-10 spec of a syntax. I
don't really like this syntax, but it is "official" inasmuch as it is in
the spec. I could give a detailed critique of the spec, but this is not
the place really.
However this spec is not intended to be used to generally specify a
broker connection rather it is defined solely in the context of redirect
and failover.
I don't think a URL scheme is context dependent, even if it is defined
with a particular use case in mind.
The whole point of the scheme identifier is that it be sufficient to
determine how to parse and interpret the rest of the url in order to
locate a particular service (or resource).
And it doesn't even seem to be complete (the tls_prot_addr
specification is absent).
The BNF is somewhat unsatisfactory certainly. You _could_ even argue
that it does not allow any other transport than tcp as it stands.
Do any of the other AMQP implementations support this URL specification
for redirect/failover? If not what is the status of an
unused/unimplemented definition in an evolving spec?
The point is that the right/responsibility to define a scheme identified
as 'amqp' lies with the AMQP group and they *have* specified such a
scheme (though they haven't registered it). Until they revise that
definition, I think that is the only one that has any official standing.
Though it has been superceded, I think
http://tools.ietf.org/html/rfc1738 is still intuitively understood as a
blueprint by many for extending a generic syntax to different protocols.
That I think was the justification behind supporting the scheme you
described, and that is the reason that I think we should not expand
beyond that blueprint (and should ideally correct the separator between
username and password is persisting with this).
Since it is in the 0-10 specification, an 0-10 implementation should
ideally recognise the official amqp schema and certainly should not use
another format with the same schema identifier in the places the
specification refers to explicitly.
As far as I can see there is no equivalent definition in the AMQP 1.0
spec - did I miss it? If I did what is the scope of use of this URI
definition? If it is absent how does 1.0 deal with redirect/failover?
The url in 0-10 was included as a way for a broker to inform clients of
alternate 'locations' for the service it offered (through the known-host
field of connection.open-ok or through the failover exchange).
That aspect is not addressed by the 1.0 specification. (I suppose in
theory there may in the future be a connection property registered that
provides similar information, or a node that broadcasts messages similar
to the failover exchange.)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
