[rabbitmq-discuss] Implementation / Specification Stability?

Fri Oct 19 16:37:39 BST 2007

Hi Landon

Welcome to the list.  Thanks for your questions and sorry for being
slow to reply.

I have discussed them with the team and my replies are below.

On 10/19/07, Landon Fuller <landonf at threerings.net> wrote:

> I'm investigating using AMQP and RabbitMQ as our service
> infrastructure backbone.

Great!  Please tell us more - several other people have reported
similar use cases and getting them discussed on this list is an
excellent way for community members to benefit from each other's ideas
and work.

> I've run into some interesting incompatibilities between Qpid at
> RabbitMQ --  an example:
>         - Qpid does not support the Access Class
>         - RabbitMQ's client API requires it
>         - According to https://issues.apache.org/jira/browse/QPID-552, the
> Access class has been removed for 0-10, and replaced with sessions.

Across implementations: we have a java client property
(com.rabbitmq.client.ConnectionParameters.suppressAccessRequest) that
allows us to suppress access.request checks, specifically developed
for working with QPid. This, plus migration to using the 0-9 XML or
the 0-8qpid XML, lets you interoperate at a very crude level.

That is - you should be able to drop in the XML as a config file, and
let RabbitMQ do rest automatically, to achieve interop.  Let me know
if this works.

We are intimately involved with Sessions design for 0-10.  Feel free
to ask more about that here.  The access tickets will be deprecated
from the AMQP spec, since a better solution for security is on its
way.  If 0-10 ends up ratified without access.request support, we may
remove access.request entirely from rabbitmq, even from the 0-8
implementation. No other implementation supports this part of the
specification.

You can also use SSL with AMQP -- we have experimented with this in
RabbitMQ but not released code yet.

> This leads to my questions:
>         -- Is it crazy to hope for backwards compatibility with older
> clients as both the specification, and the RabbitMQ implementation,
> advance?

No you are not crazy.

At RabbitMQ we are 100% committed to interop.

>         -- Will RabbitMQ Java API compatibility be broken as the
> specification changes?

No it will not.

We are developing clients with seamless interop.

MORE pedantically .... For 0-8 to 0-10 compatibility, the important
idea is to program to the model. The model isn't changing too far -
queues, exchanges, consumers, and bindings all still exist - so
*designing* for AMQP will be very similar. The API will change, but
will not change drastically. There will be added complications around
session setup and teardown, but the core operations (publish, get,
consume, declare, delete) will map in an obvious and mechanical way
from 0-8 to 0-10.

> In other words, am I engaging in massive foot-shooting by trying to
> build on AMQP now, and should I exercise judicious patience?

No you are not shooting yourself in the foot at all :-)

We have production users today who (as I understand it) are happy with
0-8, and are happy with the upgrade path should they need to follow
it.

> Thanks!
> Landon Fuller

My pleasure

alexis

-- 
Alexis Richardson
+44 20 7617 7339 (UK)
+44 77 9865 2911 (cell)
+1 650 206 2517 (US)