[ http://issues.apache.org/jira/browse/QPID-9?page=comments#action_12456461 
] 
            
Martin Ritchie commented on QPID-9:
-----------------------------------

Completed: At revision: 483503  

Encoding updated based on the FieldTable Proposal:
----------------

   Field tables are binary structures that contain packed name-value pairs.
   Each  name-value pair is a structure that provides a field name, a field
   type (referred to as the discriminator), and a field value.

   The following types can be stored in a field table:

   *  A boolean that can take one of the values True or False. The value is
   encoded  as  a  single  byte  where the value 0 represents false and the
   value 1 represents true. The discriminator is the character 't'.
   *  A  range  of  different  sized  signed  values. In each case they are
   encoded  using  two's complement. The list below shows the sizes and the
   discriminators:
   8: b
   16: s
   32: i
   64: l

   *  A  range  of  different  sized unsigned values. In each case they are
   encoded as an unsigned binary number. The list below shows the sizes and
   the discriminators:
   8: B
   16: S
   32: I
   64: L

   *  Floating point types. Floating point types are encoded using the IEEE
   754  standard.  For  full  details of that encoding please see the "IEEE
   Standard   for  Binary  Floating-Point  Arithmetic,  ANSI/IEEE  Standard
   754-1985". The different precisions supported are:
- single precision, with discriminator f
- double precision, with discriminator d
-  double-extended, which has an exponent of at least 15 bits in length and
a signed fraction of at least 64 bits, with discriminator D

   * An ASCII string type, containing ASCII characters. Encoded as a 2 byte
   unsigned  integer as the size followed by the characters, using one byte
   per character with an ASCII encoding. Discriminator 'c'.
   *  A  wide string type, containing characters encoded using the broker's
   configured  encoding  for  wide characters. Encoded as a 4 byte unsigned
   integer  as the size in bytes followed by the bytes of data. Examples of
   encodings are UTF-8 and UTF-16. Discriminator 'C'.
   * A date time type, containing a 64 bit unsigned integer that represents
   the  time to a granularity of seconds encoded in POSIX  time_t format. A
   value  of  536457599  corresponds  to Wednesday December 31 23:35:59 GMT
   1986. This has a descriminator 'T'.
   *  A  binary  data  type,  to  allow encoding of arbitrary data. This is
   encoded  as  a four byte unsigned integer representing the size followed
   by that number of bytes. Discriminator 'x'.

With the Java basic types being encoded as follows:

// As above types
BOOLEAN_PROPERTY_PREFIX = t
BYTE_PROPERTY_PREFIX = b
SHORT_PROPERTY_PREFIX = s
INT_PROPERTY_PREFIX = i
LONG_PROPERTY_PREFIX = l
FLOAT_PROPERTY_PREFIX = f
DOUBLE_PROPERTY_PREFIX = d

Unsigned types have not been implemented

STRING_PROPERTY_PREFIX = AMQP_STRING_PROPERTY_PREFIX;
BYTES_PROPERTY_PREFIX = AMQP_BINARY_PROPERTY_PREFIX;
CHAR_PROPERTY_PREFIX = AMQP_ASCII_STRING_PROPERTY_PREFIX;

The problem with the CHAR encoding results in standard ASCII strings being 
truncated. However we need to know the difference between a single char and a 
string property.

> Missing support for field table types D, T and F
> ------------------------------------------------
>
>                 Key: QPID-9
>                 URL: http://issues.apache.org/jira/browse/QPID-9
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Common
>            Reporter: Alan Conway
>         Assigned To: Martin Ritchie
>            Priority: Minor
>
> The spec defines these additional types. This area may be in flux so check 
> spec status before implementing:
> / 'D' decimal-value
> / 'T' timestamp
> / 'F' field-table
> Needs to be addressed across all languages and the python headers exchange 
> tests should test all types.
> The field table also does not support sufficient types of values for JMS 
> support see message thread:
> https://amqp.108.redhat.com/servlets/ReadMsg?list=dev&msgNo=169
> Possible a possible temporary work around would be to use encoded String 
> values 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to