qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject P
Date Wed, 10 Sep 2014 16:33:10 GMT
On Tue, 2014-09-09 at 20:53 +0200, Rob Godfrey wrote:
> On 9 September 2014 20:39, Fraser Adams <fraser.adams@blueyonder.co.uk>
> 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 <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
> >
> >



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


Mime
View raw message