[rabbitmq-discuss] ? short-string encoding and rabbitmq 2.0.1
james.anderson at setf.de
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.
>> 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?
> That should be possible by inspecting the server properties which are
> returned by the server during protocol negotiation. If a library
> 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
>> "gratuitously" disregard it. given the versioned nature of the
>> as demonstrated by the variations to framing, there is no inherent
>> reason that the type codes be identical across version. there must
>> been more at issue than the errata describes.
> I can assure you that there is nothing gratuitous about the way
> 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
there would not be anything inherently wrong with that.
>> in any case, did their discussion ever progress further? can one
>> that discussion to proceed to a conclusion? to a ratified errata
>> for the
>> specification itself? if one expects implementors to follow a
>> published, standard specification to which the implementations
>> 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?
More information about the rabbitmq-discuss