I'm afraid that your response was as clear as mud to me Rob, I'm having
a "thick" day today :-(
I did read the spec. and the RFCs, but frankly I work best with concrete
examples.
You say "
the content type is (only) to be used when the data is being
sent as an opaque "data" section and in that case it enables the recipient
to interpret the opaque data correctly
"
That's interesting, and seems a bit overrestrictive.
As I say I'd quite like to use "application/json" so that I can use AMQP
String but have the application interpret that as JSON, which seems like
a perfectly reasonable use of the general concept of content-type and
certainly how one would use content-type in something like HTTP (which I
would have assumed that the AMQP 1.0 behaviour would most reasonably
have been modelled after).
If content-type isn't the correct place to pass information about the
interpretation of the String I'm describing then I'd assume that
annotations would be where I should go? Though I have to say that
content-type=application/json seems by far and away the most natural
place to describe the message content as being JSON.....
Frase
On 09/09/14 11:31, Rob Godfrey wrote:
Hi Frase,
ignoring any transformations that may take place in a client library
between setting the content type in the API and what actually goes out on
the wire... the AMQP 1.0 specification defines content-type as follows
(see:
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-properties
):
The RFC-2046 [RFC2046
<http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html#anchor-RFC2046>]
MIME type for the message's application-data section (body). As per
RFC-2046 [RFC2046
<http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html#anchor-RFC2046>]
this can contain a charset parameter defining the character encoding used:
e.g., 'text/plain; charset="utf-8"'.
For clarity, as per section 7.2.1 of RFC-2616 [RFC2616
<http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html#anchor-RFC2616>],
where the content type is unknown the content-type SHOULD NOT be set. This
allows the recipient the opportunity to determine the actual type. Where
the section is known to be truly opaque binary data, the content-type
SHOULD be set to application/octet-stream.
When using an application-data section with a section code other than
*data*, content-type SHOULD NOT be set.
So, in essence the content type is (only) to be used when the data is being
sent as an opaque "data" section and in that case it enables the recipient
to interpret the opaque data cofrrectly
Hope this helps,
Rob
On 8 September 2014 20:01, Fraser Adams <fraser.ad...@blueyonder.co.uk>
wrote:
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: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
