On Thu, 2014-09-11 at 11:55 +0100, Gordon Sim wrote:
> 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.
I'm swayed by the arguments that we shouldn't mix content-type and AMQP
encoding on the wire. Fraser's original problem (send a string of
application/json) is not hard to handle with our existing APIs:
In C++:
std::string data = ...
m.setContentBytes(data)
m.setContentType("application/json")
On the wire the C++ client uses a data section if you setContentBytes()
and an AMQP value section if you setContentObject().
With Messenger this does the trick:
m.put(Message(address='localhost/qq', body='xxx', inferred=True))
Note the body must be of type str or bytes, not unicode. inferred=True
makes proton infer the section type from the body type, bytes is treated
as a data section. The default inferred=False always encodes an AMQP
value section, so even str or bytes would be encoded as an AMQP string.
The docstring for inferred was missing I've fixed that on trunk.
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
