Martin,
Martin Ritchie wrote:
On 28/08/07, Matthias Radestock <[EMAIL PROTECTED]> 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.
