[Fwd: Re: Python Client for RabbitMQ/AMQP?]

[Martin Sustrik]

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

[Matthias Radestock-2]

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

[Michael Arnoldus]

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-2]

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
[phone] (UK)
[phone] (cell)
[phone] (US)

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss