Robert Godfrey wrote:
Thats really just been me, and I accept I am being rather pedantic! To
again repeat what I tried previously to say, I am not at all against
adding to the protocol. I would however (where feasible) much prefer
that we didn't actually break it for simple scenarios. My view should be
taken purely as the opinion of one person though!
I agree with you... I think my point of view is that the broker should not
require the clients to be anything other than compliant with the AMQP spec.
However we may choose to "enhance" the spec that the broker accepts in
anticipation of such changes being adopted, as long as the changes do not
prevent other clients from connecting.
Further I think that when operating as an AMQP client, each of the client
packages should be capable of communicating with any AMQP compliant broker
(of the relevant version of the spec).
However, we may choose to operate the client in a mode which requires our
extension (and therefore our broker, and possibly the other endpoint to be
an instance of our client). this is the case for JMS compliance.
I think the problem is that at the moment the Java client package does not
have a good, separate, AMQP API, and so the only mode to operate in is "JMS
Compliance" and JMS compliance and AMQP compliance are (currently)
incompatible.
I would be a strong supporter of creating a distinct AMQP API for the Java
client, which would be guaranteed to work against any AMQP broker, and
to be
able to communicate with any other flavour of AMQP client.
I'm in full agreement with you there. My original post was an attempt to
see whether we could, through only simple changes that did not break JMS
compliance, allow the java client in JMS mode to at least connect to any
AMQP broker and exchange messages providing any of the non-string
property types are avoided. i.e. a restricted use of the JMS mode until
another level of java client exists (or the protocol is updated for
standard JMS compliance).
