qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: New draft of OASIS AMQP Management specification uploaded
Date Fri, 14 Feb 2014 13:37:57 GMT
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.

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 
<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 
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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message