[rabbitmq-discuss] [Fwd: Re: basic.consume filter arg [was: Re: AMQP v0-9]]

[Matthias Radestock]

Martin,

Martin Ritchie wrote:
> On 28/08/07, Matthias Radestock <matthias at lshift.net> wrote:
>> Will the flag also work for the python test suite?
> 
> I haven't done any development work on the Python.
> I only implemented the flag for the Java Client suite so the python
> may need to be rebuilt against a true 0_8 spec file.

That is fine, in a way, and is what we are doing now.

The problem though is, again, the confusion arising from the fact that 
the test suite pulls in the Qpid-modified 0-8 spec - both by default and 
when specifying "0-8" as the specfile. We have had complaints from 
people who ran the test suite that way against RabbitMQ and were 
surprised to see errors.

>> What about the server side of things, i.e. ensuring that a client which
>> conforms to the official 0-8 spec can talk to a Qpid server? Looking at
>> the differences between the official spec and the one in the qpid source
>> tree, there are two places where interop will get broken if the server
>> is not constrained to official 0-8 behaviour:
>>
>> - it must accept basic.consume messages without the filter arg
>>
>> - it must not send a basic.recover-ok response
>>
>> How are you planning to handle this?
>>
> Indeed this will be an issue for interop. Currently the broker always
> sends a recover-ok and from what I can see taking a brief look the
> Consume method always reads the arguments field from the consume body.
> What I guess that the Qpid C++ and .Net clients work correctly with
> the Java broker as they all use the same spec file.
> 
> Unfortunately we are to late to make changes to the M2 release which
> should be just as soon as we can get it voted through... though there
> is an argument that this is a fairly major interop issue and a similar
> STRICT_AMQP flag should be added to the Java M2 Broker to facility
> AMQP interop. The changes wouldn't take much work so I've copied the
> Qpid-Dev list in to see if they are happy to make this change for M2.

A flag would be good but is still far from ideal, for two reasons:

1) as I mentioned above, it causes all sorts of headaches for other 
implementations and users when an AMQP broker advertises support for 0-8 
during protocol negotiation but the departs from the spec in crucial 
areas that break interop at fairly low levels of the protocol.

2) the protocol flavour (i.e. official 0-8 vs Qpid-modified 0-8) should 
be settable on a per-connection basis. Otherwise, for example, you will 
not be able to connect to a Qpid broker with a non-Qpid client unless a) 
the broker was started with that flag, and b) all Qpid clients are 
started with that flag.

The cleanest solution to all the above would be to use a version number 
other than 0-8 for the Qpid-modified 0-8 protocol, and for the broker 
and clients to support both that and the official 0-8, and negotiate an 
appropriate fit. That is problematic though because there isn't room in 
the version numbering scheme for, say, a 0-8-1.

An alternative might be for the Qpid clients and servers to detect each 
other via the product info passed as part of connection negotiation. 
Then, when a Qpid client meets a Qpid broker they could automatically 
speak Qpid-modified 0-8 whereas when paired up with anything else they 
would revert to standard 0-8.


Regards,

Matthias
PS: I have copied the rabbitmq-discuss list, where this thread originated.