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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org