[rabbitmq-discuss] ? short-string encoding and rabbitmq 2.0.1
james.anderson at setf.de
Fri Oct 22 16:16:17 BST 2010
thank you for your note.
On 2010-10-22, at 13:53 , Simon MacMullen wrote:
> On 22/10/10 12:44, james anderson wrote:
>> 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
>> 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 page.
> 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?
the errata describes a mail thread which includes contributions from
tony [garnock-jones] and john o'hara. a link would be helpful here.
without additional background, it is difficult to comprehend, why a
standard would set one encoding and two prominent implementations
would "gratuitously" disregard it. given the versioned nature of the
protocol, as demonstrated by the variations to framing, there is no
inherent reason that the type codes be identical across version.
there must have been more at issue than the errata describes.
in any case, did their discussion ever progress further? 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.
More information about the rabbitmq-discuss