You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Gordon Sim (JIRA)" <ji...@apache.org> on 2015/04/09 18:06:13 UTC

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

     [ https://issues.apache.org/jira/browse/QPID-6328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gordon Sim reassigned QPID-6328:
--------------------------------

    Assignee: Gordon Sim

> [C++ Messaging] What to do with unsupported data types?
> -------------------------------------------------------
>
>                 Key: QPID-6328
>                 URL: https://issues.apache.org/jira/browse/QPID-6328
>             Project: Qpid
>          Issue Type: Bug
>          Components: C++ Broker, C++ Client
>    Affects Versions: 0.30
>            Reporter: Chuck Rolke
>            Assignee: Gordon Sim
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org