Hi, I hadn't really given this much thought until yesterday. We have made a big point to ensure that the Qpid product interoperates, however, we have only gone as far as ensuring this from our little world of Qpid. As a result we now have C++, C#, Java, .Net, Python, Ruby all interoperating via the Java broker and that is great.
It ignores the bigger picture and this is where I think we need to take a moment. Interoperability was one of the highest goals for M2, but is interoperability with ourselves really enough? Given that our 0_8 spec is a hybrid with some 0_9 and 0_10 features can we really claim that this is an AMQP product? Talking from the Java side for a moment. We have done some work to ensure our Java client works with standard AMQP brokers, through the use of the STRICT_AMQP flag. However, I am reminded again that whilst this stops the client using non compliant options it doesn't stop the framing sending the non-compliant frames! I think we could quite easily change our clients to be AMQP 0_8 compliant IIRC the only changes we have made are: - it must accept basic.consume messages without the filter arg - it must not send a basic.recover-ok response - Additional return types What I propose is that we use a protocol initialiser of QPID rather than AMQP for our current spec file. We can decide on a client by client basis which variant we wish to present by default, in the Java it would be QPID switching to AMQP with the STRICT_AMQP flag. Given that the spec changes are very minor I believe that supporting both AMQP and QPID protocols simultaneously would be very easy. Perhaps we are to late for M2 given the extensive testing that would need to be repeated however I don't think that Qpid and the AMQP protocol can wait for this change. I'm interested to know what others think. If you agree that it is important then I can make time to implement the above changes in the Java. Of course if you think there is more to the changes than mentioned above then that would be good to hear too. -- Martin Ritchie
