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

Sat Oct 23 00:38:27 BST 2010

good evening emile,

thank you for your note.

On 2010-10-22, at 18:18 , Emile Joubert wrote:

>
> Hi James,
>
> [...]
>
>>> 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?
>
> That should be possible by inspecting the server properties which are
> returned by the server during protocol negotiation. If a library  
> wishes
> to use short strings and interoperate with multiple brokers then that
> would be the only way at present.

in other words, "yes", despite the technical capacity inherent in the  
standard interoperability now requires implementation negotiation.
>
>> the errata describes a mail thread which includes contributions from
>> tony [garnock-jones] and john o'hara. a link would be helpful here.
>
> That discussion may not have taken place in public.
>
>> 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.
>
> I can assure you that there is nothing gratuitous about the way  
> RabbitMQ
> interprets the spec.

absent the insights achieved in the private discussions, the rabbitmq  
interpretation is no more or less necessary than the qpid-0-9 v/s  
amqp-0-9-1 type code incompatibility. the text in the errata does  
little to justify the interpretation.

> We believe the spec contains a mistake in this case
> and we have implemented what was probably intended.

then rabbitmq shouldn't purport to conform to that version of the  
specification.
there would not be anything inherently wrong with that.

>
>> 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.
>
> The RabbitMQ project is in a good position to motivate that the
> collected errata inform subsequent revisions of the spec. If concerned
> members of the AMQP community such as yourself petition for this cause
> then it becomes ever more likely.

i am at a loss, why an outsider should need to petition for an  
obvious and evidently necessary step in a standards process, but i'll  
ask anyway: to whom?