On 28/08/07, Matthias Radestock <[EMAIL PROTECTED]> wrote: > Martin, > > I understand that Rob is on holiday. In his absence, could you perhaps > answer the questions in the attached email regarding interop in Qpid M2? > Thanks. > > > Matthias. > PS: If you can, please reply to the original email on rabbitmq-discuss, > since at the moment it is sitting there unanswered. > > Robert Godfrey wrote: > > M2 will be using the 0-8 spec file that is within the specs directory in > > the qpid apache svn repository. > > I have to say that calling that file "amq.0-8.xml" in your source tree, > when it is different from the official spec is rather confusing. It took > me a while to notice that difference.
Point taken we should probably have highlighted the issue. Would have been great if our generator could have taken the standard spec and merged an errata file so we had a single file that showed the differences. > > It has an "arguments" argument > > (essentially the filters argument from 0-9 with the 0-10 name, not that > > names are important at the wire level). There are some other additions > > to the correct 0-8 specbut these are essentially additions, and as long > > as the strict amqp flag is passed to the qpid client then the client > > won't use them ... > > Please make sure that flag is documented very prominently. Otherwise we > are bound to get complaints from people who try to get interop to work. > > 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. > 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? > > > Matthias. 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. Off the top of my head there isn't any other items other than bugs that might prevent interop. I'm not 100% convinced about our Basic.Reject handling for instance. -- Martin Ritchie
