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. - Rob
