On Tue, 2014-09-09 at 20:53 +0200, Rob Godfrey wrote: > On 9 September 2014 20:39, Fraser Adams <[email protected]> > wrote: > > > 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. > > > > > So the rationale here is that if you put in "text/plain; charset="utf-16"'. > or something, then what does that mean? The AMQP spec says that a string > is encoded in utf8... As you said in you original mail, the AMQP type > system is supposed to be rich enough that it can be used to describe any > type. The content type is designed for the case where the data being > transferred is not encoded in the AMQP type system, but instead presented > as opaque binary data in AMQP terms. > > > > 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). > > > > > So - following the logic of the AMQP type system once could suppose that > the intended patern here would be to create a new described type (let's say > we use the description "org.apache.qpid.application/json") and use this to > send the string. > > > > 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..... > > > > > Why not send the "string" as opaque data then? Basically using content > type and an AMQP typed value is mixing two different encoding systems... > Informally clients could probably support it but it's not really the > intended use case (the spec only says SHOULD - so it's not illegal, just > strongly discouraged :-) ) >
The problem with opaque data is that then you really have to set content-type='application/json; charset=<blah>' and supply your own unicode codec, which sucks since your friendly AMQP client library will deal with all that for you if you send an AMQP string message. So I can understand the desire to say "it's an AMQP string (so AMQP deals with unicode) but with an extra hint: that string is application/json". You could invent another property name for the hint but it really feels like it belongs in content-type. Of course you have an inconsistency to resolve if somebody sets an AMQP string body with content-type='application/json; charset="utf-16"' Could we say: You MAY use content-type with an AMQP string body but it MUST NOT not have a charset and MUST be ignored by the sender. It MAY be used as a decoding hint on the receiver. > -- Rob > > > > 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 <[email protected]> > >> 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: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >>> > > > > --------------------------------------------------------------------- > > 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]
