[rabbitmq-discuss] ? short-string encoding and rabbitmq 2.0.1
james.anderson at setf.de
Sat Oct 23 00:38:30 BST 2010
good evening, michael;
thank you for your note;
On 2010-10-22, at 19:22 , Michael Bridgen wrote:
>>>> i understand this, and the code in the repository to indicate
>>>> 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
>>>> 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
>> 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
> 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".
another author was kind enough some months ago to have cleared up any
misconceptions and unreasonable expectations which i might have had
about those passages.
> 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
>> 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.
i am not cross. independent of any questions of lost time and/or
unsatisfactory documentation, i am disappointed. the amqp
specification provides sufficient technical capacity, that an
argument that the type codes need be identical between versions is
unfounded. i was not (evidently, fortunately) witness to the history,
but if the issue is that qpid claimed a combination between an 9.0.1
and an incompatible set of type codes, then the logical step would
have been to assign that set and the set in the present 9.0.1
specification a distinct versions of the specification. given which
option the choice, above, is difficult to comprehend.
More information about the rabbitmq-discuss