On 14/02/14 13:05, Rob Godfrey wrote:
Good spot - you obviously know AMQP better that the authors :-)
I wish! TBH it's something that I'm fairly familiar with in JMS, so
non-primitives or String property values always trigger alarm bells with
me. I wondered initially if it was legal AMQP though not legal JMS so I
looked up the AMQP specification to check, so no I'm afraid I can't
*really* claim familiarity :-)
We'll need to get that fixed up for WD06.
Cool.
Actually one other thing springs to mind (I'm sure I'll think of more
when I get back into it ;->) is it worth *explicitly* specifying that
the string type to be used should be
AMQP 1.6.20 string
A sequence of Unicode characters.
<type name="string" class="primitive">
<encoding name="str8-utf8" code="0xa1" category="variable" width="1"
label="up to 2^8 - 1 octets worth of UTF-8 Unicode (with no byte order
mark)"/>
<encoding name="str32-utf8" code="0xb1" category="variable" width="4"
label="up to 2^32 - 1 octets worth of UTF-8 Unicode (with no byte order
mark)"/>
</type>
A string represents a sequence of Unicode characters as defined by the
Unicode V6.0.0 standard [UNICODE6]
I know that it does say string in the Management Specification, but I
suspect that being explicit might not be a bad idea. The reason that I
mention this is that in C++ it's potentially more "natural" to assume a
"binary string", which in many cases can visually look the same but can
play havoc with interoperability. I've got plenty of memories where
binary strings cause ClassCastException and I ended up putting quite a
bit of defensive code in place in things like QMF code.
This request is possibly a little controversial, so it'd be good if
folks from the C++ side of the house could comment. In particular at the
moment the C++ broker Management Agent tends to populate string values
as binary (I think - it's been a while since I checked, I've definitely
had some C++ Agents passing binary strings), so this *might* have
implications for migration from QMF2 to AMQP 1.0 Management Spec. but
given that it's still in working draft we've got an opportunity to
specify out some potential ambiguity that can be a pain.
Thanks for the correction!
No worries, glad to have done something useful today :-)
Cheers,
Rob
