[rabbitmq-discuss] ? short-string encoding and rabbitmq 2.0.1
mikeb at rabbitmq.com
Fri Oct 22 18:22:07 BST 2010
>>> i understand this, and the code in the repository to indicate that
>>> the 115,6,83 at the start of the fourth line of the content vector,
>>> above, was decoded as a short 16/signed instead of the intended six byte
>>> short string. given which state, the subsequent vector
>>> <<84,82,73,78,71,7,80, ...>> matched no pattern. do i understand these
>>> events correctly?
>> See http://dev.rabbitmq.com/wiki/Amqp091Errata#section_3 for a bit
>> more information, but in short this is an area where we believe the
>> spec to be incorrect.
> ok. it would help, if the page which describes that rabbitmq implements
> 0.9.1 were to include something to the effect that the specification
> which version 2 purports to support is not the one to which the page
> links, but some other. perhaps it could also include a link to that
> other specification, or at least to the wiki errata page. perhaps the
> release notes page could include the topic. or perhaps the release news
In general RabbitMQ tries very hard to implement the letter of the
specification; however there are a few things in the published AMQP
0-9-1, as in most specifications, that are either ambiguous or
inconsistent. In those cases we set out in the errata what is it
RabbitMQ /does/ do. This is not an unusual situation.
As an egregious though amusing example, see the published *AMQP 0-8*
specification under the heading "4.2.2 Protocol Header".
If you are cross because this cost you time and effort, then I
sympathise -- we've spent rather a lot of time and effort ourselves
trying to implement 0-9-1 in a way that it consistent /and/
interoperates with other implementations.
>> The upshot is that there isn't a way to put short strings in tables;
>> you have to use long strings.
> the question remains, whether rabbitmq's intention is that, a library
> which purports to implement the standard now needs to not only negotiate
> protocol version, but also implementation?
Sadly, it is a choice between being faithful to the specification and
working with the implementations extant. For us, too.
> can one expect
> that discussion to proceed to a conclusion? to a ratified errata for the
> specification itself? if one expects implementors to follow a ratified,
> published, standard specification to which the implementations purport
> to conform, that would be appropriate.
I'm not going to disagree.
More information about the rabbitmq-discuss