[rabbitmq-discuss] ? short-string encoding and rabbitmq 2.0.1

[james anderson]

good evening, michael;

thank you for your note;

On 2010-10-22, at 19:22 , Michael Bridgen wrote:

> James,
>
>>> <snip>
>>>> i understand this, and the code in the repository[3] 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?
>>>
>>> Yes.
>>>
>>> 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
>> page.
>
> 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.
>>
>> evidently.
>> 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.

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.