Martin Ritchie wrote:
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
The most problematic divergence from the spec for me is the extra field in basic.consume which was I believe addressed by 0-9. That change affects not only the java client & broker (which might use it) but also the c++ client and broker which are built using that spec file (and the python client if pointed at that file).
- it must not send a basic.recover-ok response
This would affect the python client if using that spec. It doesn't affect the c++ client or broker.
- Additional return types
Do you mean the additional field table value types? If so I'm less concerned with these as it is easy to avoid sending them from the java client.
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.
I'm not convinced we would need that. We can signal the implementation of both client and broker in the connection.start/start-ok handshake.
Neither the python client nor the c++ client make use of the extensions. The python client would be 0-8 compatible by pointing it at a correct spec file at runtime I believe. The c++ client would I think just need to be built against a clean spec file, as would the c++ broker which does not implement the extensions.
The biggest problem I see from the java side is that you want to be able to switch between two versions of the generated basic.consume method definition.
You also need some additional method definitions which are less problematic. The 'gentools' generator allows additional xml fragments to be supplied as input to the generation process so that extension methods (or even additional arguments) can be kept separate from the official spec file. I've lost track of whether the 0-8 java code is using that for generation at present.
If you can figure out a good way of getting the extensions you may need into the java code without altering the official spec file, and if you could restrict use of those extensions to the case where you know you are talking to a compatible broker (set AMQP_STRICT on connection handshake based on server properties?) then I think we would have a workable solution for returning to 0-8 compliance.
