On 09/21/2011 04:09 PM, Fraser Adams wrote:
Jiri/Rajith/Gordon,
I'm getting *deeply* concerned by this thread.
I've already raised pretty vigorously my views that interoperability
should be the default position. It has been some time since I looked but
I seem to recall reading that in AMQP "String" is defined as UTF-8 so
that IMHO makes things pretty clear that the C++ etc. runtimes should be
defaulting strings to UTF-8.
AMQP defines wire encodings for both binary and string types. The
std::string type in c++ can (depending on its contents) be mapped to
either of these categories.
Where the protocol defines a particular type, there is no difficulty
(e.g. for routing keys).
The issue here is in more unrestricted use of the type system, e.g. in
the application defined 'properties' attached to a message or the
arguments to a bind call (both of which AMQP defines simply as a map).
In such cases the application can provide an indication as to how they
want a particular std::string instance to be encoded failing which we
use a default. The current default in all cases is vbin as any
std::string is guaranteed to be a valid vbin.
You have made the point, which I agree is fair, that in particular
contexts (message properties, address strings etc) the vast majority of
cases will in fact be dealing with textual data. Assuming utf8 if no
explicit encoding is indicated in these contexts would increase the
incidence of the intended encoding being used.
My previous mail in this thread listed two obvious ways to do this with
implications of each. I don't think it should cause any deeper concern.
i get the C++ "but strings are just byte
arrays" thing, but to be fair from an interoperability perspective I
tend to take the perspective that property types should be limited to a
similar range to JMS. If binary properties have to be supported then
that should be the exception case with a specific method call
(preferably prefixed with nonInterop or somesuch) used to make it clear
to clients that what they are doing could break things.
I agree that it is important to highlight such features that while valid
in AMQP may bot be for a JMS mapping adhering strictly to the JMS
specification (e.g. as when sending nested map messages, which we do
alert users to in the programming guide).
As above, I also agree that genuine binary properties are likely to be rare.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
