Interoperating with a non-qpid client reveals difficulties handling non-native data type, such as Amqp 1.0 char (utf32). The following issues are related:
|QPID-6314||Message containing utf32 value is rejected at broker ingress.|
|QPID-6315||Message containing timestamp passes broker ingress but Messaging client converts timestamp to INT64. Messaging client cannot interoperate using timestamp data type.|
|QPID-6327||Message containing a map with a utf32 value passes broker ingress but Messaging client throws decoding the message. Client must use try-catch to recover from failed message decode. Client cannot access any of the rest of the map message.|
The difficult data types are
As they have no natural representation in C code.
One possible resolution is to have an external encoding in Messaging that describes the data. This is identical to the way Messaging handles strings. A vbin8 string and a utf8 string are both 'string' data type in the customer code and he needs to use the getEncoding and setEncoding methods to differentiate them. A possible scheme:
|uint32||uint32, utf32, decimal32|
|uint64||uint64, decimal64, timestamp|
This still leaves the decimal128 data type without a representation.