Gordon's recent post
When the message is created it looks like this:
std::string messageContent("example text");
qpidMessage.setContentType("text/plain");
qpidMessage.setContent(qpid::types::Variant(messageContent));
Use Message::setContentObject() instead and set the encoding, e.g.
change the last line to:
qpidMessage.setContentObject(messageContent);
qpidMessage.getContentObject().setEncoding("utf8");
prompted me to ponder about what and what is not the correct use of
content-type in AMQP 1.0.
So for AMQP 0.10 IIRC in qpid::messaging the content type was used to
indicate certain AMQP types, for example in particular amqp/list and
amqp/map now as I understand it for AMQP 1.0 the AMQP type system is
sufficiently self-describing such that maps/lists/whatever don't need
such things as content-type, however the various APIs do need some
mechanism to specify the relevant type hence (I think) the
setContentObject() mechanism in qpid::messaging
is that correct?
Why I ask is that for my JavaScript stuff although I've incorporated a
mechanism to automagically serialise and deserialise JavaScript Objects
to the AMQP type system I also quite fancy including a mechanism that
takes a JavaScript Object and serialises it as JSON in an AMQP String
(obviously assuming that it is a data object that is actually
convertable to JSON) similarly I'd like to be able to receive a JSON
object and deserialise it into a JavaScript object.
My thinking is that this is actually a good use of the AMQP content-type
and in this case setting content-type to "application/json" is the right
thing to do to give the API the right hints to treat Strings as JSON.
Is my logic and understanding of the use of content-type in the AMQP 1.0
spec. reasonable?
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
