[
https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475662
]
Tomas Restrepo commented on QPID-336:
-------------------------------------
Looking a bit more closely on this issue, it appears I was wrong and
QpidHeaders is indeed implemented on top of a FieldTable, but adds its own
naming scheme/encoding for property names. This should probably be rewritten to
simplify it.
The biggest problem with the fieldtable stuff now seems to be that you can't
read a field table from a bytebuffer (mea culpa, didn't catch this before in my
tests) because FixedByteBuffer.slice() isn't implemented. Implementing it would
probably mean creating yet another ByteBuffer-like class, so at this point, my
humble opinion would be that a complete rewrite of Qpid.Buffers would be in
order.
As part of that, here are some suggestions to simplify this:
- let's start with the simplest implementation that satisfies our needs. We
don't need the entire set of functionality supported by MINA in this respect
(at least right *now*). For example, all the put(position, value) and
getXXX(position) members could go as they are not used anywhere and are not
implemented in any of the ByteBufferClasses.
- Implement the simplest byte buffer allocator at first. For example, the
SimpleByteBufferAllocator class has its own ref-counted ByteBuffer-derived
class, which is not really useful at this point (since we don't release
anything after the refcount drops to zero anyway).
- Loose all the byte buffer implementations and stick with only two at first: A
core ByteBuffer implementation and a SlicedByteBuffer to support the slicing
functionality needed by the FieldTable class, implemented as a simple view on
top of the other. Move as much functionality unto the abstract ByteBuffer class
(including all base type encodings) so that subclasses only need to override as
few methods as absolutely needed (which I think don't need to be more than 6-10
methods).
> .NET client support for field table types requires extension (interop issue)
> ----------------------------------------------------------------------------
>
> Key: QPID-336
> URL: https://issues.apache.org/jira/browse/QPID-336
> Project: Qpid
> Issue Type: Bug
> Components: Dot Net Client
> Affects Versions: M1
> Reporter: Marnie McCormack
> Assigned To: Marnie McCormack
> Attachments: QPID-336.diff
>
>
> If you send a message from a Java client and then consume from a .NET client
> there's an error:
> A first chance exception of type 'Qpid.Framing.AMQFrameDecodingException'
> occurred in qpid.common.dll
> Additional information: Unsupported field table type: 'x' charcode120
> In the .NET case, this kills the connection to the broker as well, which
> would seem to be a little extreme.
> .NET client needs to support the same set of field table types as Java client.
> See Field Table extension proposal for AMQP from 108 wiki:
> Field Table Change 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.
> Currently the following values can be stored in the field table.
> 4.2.5.5 Field Tables
> Field tables are long strings that contain packed name-value pairs.
> Each name-value pair is a structure that provides a field name, a field type,
> and a field value.
> A field can hold:
> a tiny text string ('S')
> a long string ('S')
> a long signed integer ('I')
> a decimal ('D'), a date and/or time ('T')
> or another field table ('F').
> It is proposed that this section be changed to:
> 4.2.5.5 Field Tables
> Field tables are long binary values that contain packed name-type-value
> triples.
> Each name-type-value triple is a structure that provides a field name, a
> field type, and a field value.
> A field can hold:
> 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 character. Encoded as a single character with an ASCII encoding.
> Discriminator 'k'.
> 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 NULL string, No Encoded value. Discriminator 'n'.
> 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'.
> Another field table 'F'.
> Guidelines for implementers:
> Field names MUST start with a letter, '$' or '#' and may continue with
> letters, '$' or '#', digits, or underlines, to a maximum length of 128
> characters.
> The server SHOULD validate field names and upon receiving an invalid
> field name, it SHOULD signal a connection exception with reply code
> 503 (syntax error). Conformance test: amq_wlp_table_01.
> A peer MUST handle duplicate fields by using only the first instance.
> The above implies that there is a configured wstring encoding at the broker
> level. I propose that the Connection.Tune method gets an additional field
> indicating the encoding (e.g. UTF-16 or whatever) that is used by the broker.
> It is the client's responsibility to do any translation required.
> It is not feasible for the encoding to be negotiated on a per-client basis
> since that would imply that the broker could do the translation which would
> mean that the broker needs examines every content header's field table.
> Adapted from original email by Robert Greig
> (https://amqp.108.redhat.com/servlets/ReadMsg?list=dev&msgNo=169)
> Retrieved from
> "https://wiki.108.redhat.com/wiki/index.php/FieldTableChangeProposal";
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
