On 09/10/2014 08:50 PM, Rob Godfrey wrote:
Part of the issue here, I think, is that we are not terribly (at all?)
clear on what each API might do with a particular input from the client
application, and how that might be treated by the library on the receiving
end.
Fpr qpid::messaging, there are two ways to set the content:
(i) setContentBytes(), which is just a more explicit alias for the
original setContent() and
(ii) setContentObject()
Using the setContentBytes() method, or the original setContent() method,
the message sent out will have a data section containing the bytes.
Using the newly added setContentObject() method, the message will be
sent out with an amqp-value section matching the type of the content object.
When a message is received over AMQP 1.0, if the body is an amqp-value
section it will be decoded and made available in decoded form through
the getContentObject() method. (The raw bytes will incidently also be
available via getContentBytes()). If the body is a data section, the
bytes will be available as received via either getContentObject() or
getContentBytes().
The content type is accessible through specific accessors on the Message
class; the content encoding is at present accessible as a
'pseudo-property' named x-amqp-content-encoding.
[At present if on an outgoing message you set the content via
setContentObject(), the value returned by getContentBytes() does not
reflect that, and vice versa. This is felt by some to be a problem, but
I've not myself had any time to look for a solution.]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
