[rabbitmq-discuss] Getting Started with RabbitMQ

Wed Feb 18 08:47:35 GMT 2009

Joern,

Thanks again for this wikipedia work, it is great for AMQP.

On Wed, Feb 18, 2009 at 8:31 AM, Joern <opendev at gmail.com> wrote:
>
> I used 0.10 as it is (IMHO at least) a much more structured read than
> it's predecessors. Some concepts however (such as sessions) are not
> directly present in RabbitMQ with 0.8 being it's target (btw - how far
> down the road is 0.10?).

Speaking for the RabbitMQ team, we have no current plans to implement
AMQP 0-10.  Instead we're moving to 0-9-1, which is a very small
change from 0-8 and will lead to interop with other brokers.  From
there we shall attend AMQP 1.0.

Speaking for the AMQP Working Group: there is 1.0 work under way,
which among others things aims to refactor and simplify 0-10.  It is
hoped that drafts and even release candidates will be published for
review by summertime.  We've learnt in the past that it is not prudent
to put hard dates on GA release, because baking protocols takes time
and care.

> Maybe someone with more knowledge about the
> details could write something about the key differences between the
> revisions?

It's probably a good idea to do that if it can be done briefly.

How about: The main technology introduced in 0-10 and subsequently, is
the 'session' which abstracts a bilateral conversation across
failures.  Flow control and distributed transactions should also be
mentioned, and more rigrorous support for JMS.

IMO - These concepts are all important, but do leave the 0-10 reader
craving a simpler approach.

BTW, JMS has annoying and lovely impedance mismatches with AMQP.   It
truly is a hairy thing.

> Related to that problem is that the article should highlight the
> failure modes (returns, the mandatory / immidiate flag, manual acks,
> delievery modes and unroutable messages) - these are quite important
> things for most users of AMQP.

Yes, that is a good point.  Arguably the whole idea of a 'message
protocol' is to standardise how parties get out of trouble.

> Since these have changed between the
> revisions it would make quite a lot of sense to detail failure modes
> and error handling in a form where the differences between the spec
> revisions could also be highlighted.

Maybe ... I'd hold back from turning the wikipedia page into a new
spec though ;-)

alexis

> Best regards,
>
>
> Joern
> --
>