[rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3

Fri May 7 17:54:44 BST 2010

On Fri, May 7, 2010 at 3:00 PM, Rafael Schloming <rafaels at redhat.com> wrote:
> Alexis Richardson wrote:
>> Davorin
>>
>> On Thu, May 6, 2010 at 7:16 AM, Davorin Rusevljan
>> <davorin.rusevljan at gmail.com> wrote:
>>> This of course raises the question should I invest my time in learning 0.8
>>> and products that use it, or try to jump the wagon of 1.0.
>>>
>>> What would you say, in what state is 1.0 specs is it about to be published
>>> soon, and what are the plans for RabbitMQ support for it?
>>
>> The easiest path is to learn 0-8 or 0-91 which is very similar and better.
>
> I would differ with this slightly. Obviously if you need a production
> quality solution immediately, then you need to evaluate what projects
> and/or vendors offer right now, however I don't know if diving into a
> specification targeted at implementors is the best way to do that. Most
> likely you'll need to decide based on what features you need and
> whether/how they are exposed by the various implementations.
>
> On the other hand if you're interest does lie in the specification, the
> 1-0 document is specifically intended *not* to require any knowledge of
> prior versions to comprehend, and in some cases familiarity with older
> versions can even result in some confusion, although Michael's
> unofficial guide certainly helps with that.
>
> Either way, we could definitely use feedback from people who are reading
> the 1-0 version of the document with fresh eyes that are not weighed
> down by the baggage from earlier versions of the spec. So if you have a
> few hours to spare, any comments would be greatly appreciated, although
> due to the lack of production ready implementations, this may be as much
> for the benefit of the working group as it is for you in the short term.

Actually I think that having in mind 0-91 helps getting through the
new document.

IMHO the greater generalization poses a bigger challenge when it comes
to explaining and understanding the protocol.

Just take as an example the "link" entity.

Looking at the picture in page 13 of document [1], you don't see the
filter - or a filtering entity at all, messages magically (or because
they're clever) follow the right link and go from the initial node to
the right node for their color.

In many other contexts links are entities where there isn't much action.
The usual link abstraction represents a connection or relationship and
it either exists or not, may have a direction, but it doesn't operate
more complicated operations.
If I describe a network connection as a link between two endpoints it
means I'm only interested in describing the fact that "this entities
are connected".
If I describe the same connection but I'm interested in how the
packets are routed through and which will be filtered by the firewall,
then I'll add firewall and router entities to the schema to justify
these properties of the connection.

On the same line non destructive links are rather esoteric: a message
goes down the link, the link clones the original message, pushes one
of the clones down the pipe and sends the other back to the origin
node. This is a difficult mental model. You might try to explain it in
a way where the original message never leaves the node, but then who
clones it? The link can't since the message is not in yet so it would
be the node then but why a property of the link would trigger behavior
in the node? I know it might sound silly but I see some trickiness.
And also from the implementer point of view there's  some potential
ambiguity.

Referring to the old specs might make easier to understand how
entities of the new spec should be combined to get started in simple
scenarios. The new spec allows for much more flexibility but without
the old building blocks in mind the new adopter has IMHO a significant
chance of shooting himself in the foot.

The point I want to make is that if you read the specs the E. Tufte
way, not limited to the visual representation but also extending it to
the text there's a weakness in order of cause/effect explanation and
concepts representation which wasn't there in previous versions.

I'm not saying that the new spec are bad or can't be understood at
all, I just think that the learning curve has got steeper. I also
openly admit that I'm for sure biased by the fact that I know the old
previous versions and then they probably look easier to me just
because I know them.

To finish I noticed that there are scheduled works for a documents for
the broker implementation specs which might clear out part of my
concerns (url missing because amqp.org seems to be down or my provider
has issues).

[1] http://www.amqp.org/confluence/display/AMQP/1-0+Core+Protocol+Spec

Thanks,

Paolo

>
> --Rafael
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>