[QPID-6328] [C++ Messaging] What to do with unsupported data types?

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 0.30
• Component/s: C++ Broker, C++ Client
• Assignee: Gordon Sim
• Reporter: Charles E. Rolke
• Created: 20/Jan/15 20:31
• Updated: 29/Sep/15 21:51

Description

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:

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

• decimal32
• decimal64
• decimal128
• char
• timestamp

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:

Native type	Encodings
uint32	uint32, utf32, decimal32
uint64	uint64, decimal64, timestamp

This still leaves the decimal128 data type without a representation.

Issue Links

• blocks: QPIDIT-3 AMQP type decimal128 hangs ProtonPython shim
• blocks: QPIDIT-4 AMQP type char hangs ProtonPython shim
• blocks: QPIDIT-5 AMQP type decimal32 fails ProtonPython -> ProtonPython
• blocks: QPIDIT-6 AMQP type decimal64 fails ProtonPython -> ProtonPython
• blocks: QPIDIT-19 AMQP type char hangs ProtonPython shim