qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Use of content-type in AMQP 1.0
Date Tue, 09 Sep 2014 18:39:55 GMT
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.adams@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-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message