The easiest way (IMHO) whould be to rename (and renumber) the extended consume method which Qpid/J has introduced... and add the existing consume back in... Then the client code simply needs to have a switch to determine whether to use 0-8 consume, 0-9 consume (which has filter) or 0-8Qpid consume-extended. The method to use will be determined by the version negotiated at connection start-up.
-- Rob On 29/08/2007, Gordon Sim <[EMAIL PROTECTED]> wrote: > > 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. >
