Robert Godfrey wrote:
> I was thinking that I could probably get the Java Qpid broker to support > AMQP 0-9 (non-WIP) if there is demand. For the production uses of Qpid > that I know about 0-8 is all that will be used however. > > Martin - does OpenAMQ still accept clients wanting to talk 0-8 to it? No. We've simply updated both OpenAMQ broker and Java client to support 0.9. > I can't remember any changes off the top of my head between 0-8 and 0-9 > (non-WIP) that would prevent a 0-9 broker from accepting communication > from a 0-8 client [sorry for hijacking a Rabbit-MQ list for a Qpid / > OpenAMQ question]. 1. There was channel-id parameter added to channel.open-ok. 2. Few methods have changed IDs. 3. Matching algorithm for headers exchange was changes slightly. 4. New parameter to Basic.Consume (not used). 5. Maybe something similarly simple here... I don't recall exactly. Not a big deal, however, we are releasing new version for use in production in few days time, we have 24/7 tests done already and while the testing will be going on on the JPMC side we wouldn't like to introduce new features (like 0-8 compatibility) that would potentially threaten the stability. What about defining the minimal set of changes to 0.8 (like the five points above) all of us have to do to get 0.9 (sans WIP) and implement that. That way we would all be interoperable and nobody would have to support 2 different versions of the protocol. BTW: It took me like 1 day to implement the changes. And it was not a very busy day :) Martin _______________________________________________ rabbitmq-discuss mailing list [hidden email] http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
Martin Sustrik wrote:
> 1. There was channel-id parameter added to channel.open-ok. > 2. Few methods have changed IDs. > 3. Matching algorithm for headers exchange was changes slightly. > 4. New parameter to Basic.Consume (not used). > 5. Maybe something similarly simple here... I don't recall exactly. There are also two new error codes - 'no-route' and 'no-consumers', which need to be used in place of more generic errors in 0-8. > What about defining the minimal set of changes to 0.8 (like the five > points above) all of us have to do to get 0.9 (sans WIP) and implement > that. That way we would all be interoperable and nobody would have to > support 2 different versions of the protocol. I like that idea. We'd need to do a careful comparison of the *text* of the spec. Things like new methods and fields are easy to spot and easy to implement (at least as stubs), but subtle changes/clarifications to the semantics are much harder to identify. Matthias. _______________________________________________ rabbitmq-discuss mailing list [hidden email] http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
Guys,
I cannot tell you how happy I am to see you discussing and taking this interop thing so seriously. It just make me think I have made the right choice going with AMQP at this point in time. Thank you so much!!! Michael Arnoldus Den 23/08/2007 kl. 22.42 skrev Matthias Radestock: > Martin Sustrik wrote: >> 1. There was channel-id parameter added to channel.open-ok. >> 2. Few methods have changed IDs. >> 3. Matching algorithm for headers exchange was changes slightly. >> 4. New parameter to Basic.Consume (not used). >> 5. Maybe something similarly simple here... I don't recall exactly. > > There are also two new error codes - 'no-route' and 'no-consumers', > which need to be used in place of more generic errors in 0-8. > >> What about defining the minimal set of changes to 0.8 (like the five >> points above) all of us have to do to get 0.9 (sans WIP) and >> implement >> that. That way we would all be interoperable and nobody would have to >> support 2 different versions of the protocol. > > I like that idea. > > We'd need to do a careful comparison of the *text* of the spec. Things > like new methods and fields are easy to spot and easy to implement (at > least as stubs), but subtle changes/clarifications to the semantics > are > much harder to identify. > > > Matthias. > > _______________________________________________ > rabbitmq-discuss mailing list > [hidden email] > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss _______________________________________________ rabbitmq-discuss mailing list [hidden email] http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
Michael
Thanks! Now please let us know if you think everything works :-) Do you have the client code that you were looking for a few weeks ago? Does it work with your broker set-up? alexis On 8/23/07, Michael Arnoldus <[hidden email]> wrote: > Guys, > > I cannot tell you how happy I am to see you discussing and taking > this interop thing so seriously. It just make me think I have made > the right choice going with AMQP at this point in time. Thank you so > much!!! > > Michael Arnoldus > > Den 23/08/2007 kl. 22.42 skrev Matthias Radestock: > > > Martin Sustrik wrote: > >> 1. There was channel-id parameter added to channel.open-ok. > >> 2. Few methods have changed IDs. > >> 3. Matching algorithm for headers exchange was changes slightly. > >> 4. New parameter to Basic.Consume (not used). > >> 5. Maybe something similarly simple here... I don't recall exactly. > > > > There are also two new error codes - 'no-route' and 'no-consumers', > > which need to be used in place of more generic errors in 0-8. > > > >> What about defining the minimal set of changes to 0.8 (like the five > >> points above) all of us have to do to get 0.9 (sans WIP) and > >> implement > >> that. That way we would all be interoperable and nobody would have to > >> support 2 different versions of the protocol. > > > > I like that idea. > > > > We'd need to do a careful comparison of the *text* of the spec. Things > > like new methods and fields are easy to spot and easy to implement (at > > least as stubs), but subtle changes/clarifications to the semantics > > are > > much harder to identify. > > > > > > Matthias. > > > > _______________________________________________ > > rabbitmq-discuss mailing list > > [hidden email] > > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > > _______________________________________________ > rabbitmq-discuss mailing list > [hidden email] > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > -- Alexis Richardson +44 20 7617 7339 (UK) +44 77 9865 2911 (cell) +1 650 206 2517 (US) _______________________________________________ rabbitmq-discuss mailing list [hidden email] http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
Free forum by Nabble | Edit this page |