qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: Use of content-type in AMQP 1.0
Date Thu, 11 Sep 2014 09:12:04 GMT
Interesting discussion. We are using JSON as well as different XML based
standards as well as Google Protocol Buffers in our messages and I would
probably not expect to pack my XML, JSON or GPB data into AMQP String or
AMQP Binary. I would intuitively use / expect it to be as opaque data. I
would always try to avoid mixing the different encoding. One of the
situations where I think it can make life more complicated would be
bridging to other messaging protocols.


On Wed, Sep 10, 2014 at 8:50 PM, Rob Godfrey <rob.j.godfrey@gmail.com>

> On 10 September 2014 20:10, Fraser Adams <fraser.adams@blueyonder.co.uk>
> wrote:
> > On 10/09/14 17:33, Alan Conway wrote:
> >
> >> On Tue, 2014-09-09 at 20:53 +0200, Rob Godfrey wrote:
> >>
> >>> 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.
> >>
> >>
> >>
> > I have to violently agree with Alan here!!
> >
> > If I'm honest Rob, both of your suggestions seem a bit alien to me. If I
> > were to put on a "humble user" hat I *strongly* suspect that most normal
> > people would intuitively assume an HTTP-like pattern sending a String
> with
> > a content-type of application/json, after all that's what people do when
> > sending JSON via HTTP. Now I know AMQP is not HTTP, but there's an awful
> > lot to be said for sticking with commonly understood idioms.
> >
> Yes - and the idiom is that the data which a content-type /
> content-enconding is applied to is (without the content-type /
> content-encoding) opaque.  HTTP doesn't send strings - it sends data, which
> you can interpret by knowing the content type / encoding... and - guess
> what - we have the mechanism for doing that in AMQP - it just doesn't
> involve the use of a section type which explicitly states that it contains
> amqp-encoded data.
> I'm not saying that it isn't a better choice to use that idiom, just that
> to mix the AMQP types and the HTTP style encoding isn't going to work.  The
> content-type/encoding give you all you need to decode data, to then try to
> apply that to AMQP encoded data doesn't work.
> In the general way of things, I think it's reasonable that a receiving
> client might understand that an amqp-value section containing an
> amqp-string coupled with a content-type with no encoding on it can be
> non-ambiguously interpreted... but as a sender of a message I would say you
> should never do that.  You should send your data in a data section, since
> you are providing the encoding / type information in the content-type /
> encoding properties.
> >
> > Funnily enough we had a similar conversation the other week on the
> subject
> > of erm subject and it would seem that the AMQP 1.0 approach is to model
> it
> > after RFC-822 email subject.
> >
> > On the idea of the Described type that doesn't seem *totally*
> > unreasonable, though I'd say massively less intuitive than
> > content-type=application/json, but why on earth would you use
> > "org.apache.qpid.application/json" surely "application/json" is an IANA
> > registered content type sure the org.apache.qpid adds extra namespacing
> but
> > I doubt it's what anybody would be expecting (and yes I know in that case
> > it's no longer a content type but rather a description but I'd still
> argue
> > that the description should conform to a commonly understood idiom).
> >
> The definition of described types is that the descriptor should be a
> reverse domain name.  application/json would not be valid.  org.json would
> be valid (but we don't own it - though I doubt they'd mind if someone asked
> to register it for this purpose).
> >
> > TBH IMHO anything other that content-type=application/json with the body
> > being a string containing the JSON seems downright weird to me :-)
> >
> >
> Then you could / should use the data section type for your message, not the
> amqp-value section type - you want to convey the semantics associated with
> the value in the MIME style not the AMQP encoding style.
> I'm really not expressing a preference over which style one should use - I
> certainly think there is a strong case to be made for the MIME style having
> a greater chance of wider interoperability.  The point I am trying to make
> is that there is (for better or worse) two ways of expressing the encoding
> and semantics of the data being transferred.  Option 1 is to use the AMQP
> type system to encode your data (as an amqp-value or an amqp-sequence).
>  Option 2 is to send the data "opaque" as far as the AMQP type system is
> concerned, but with the information on encoding and semantics in the
> content-type and content-encoding properties fields.
> > As it happens I actually (de)serialise JavaScript into the AMQP type
> > system, so this idea was kind of a "nice to have" for cases where an
> > application might be sending JSON and I could then simply ask my
> JavaScript
> > client to deserialise it in a nice friendly way, but frankly I'd sooner
> not
> > implement it if it means making people use counterintuitive constructs
> :-(
> >
> >
> As above - I agree that using application/json makes complete sense if you
> want to send / receive the data in the HTTP style - but then don't send
> explicitly AMQP encoded data, use the appropriate section type.  Remember
> that you are not sending "a string" you are sending a section which is
> explicitly an "amqp-value" which can be any form of data encoded in AMQP.
> I'm not going to argue that a strong case could be made that it is a
> mistake to offer two different encoding mechanisms.  Certainly for sending
> typed data like maps and lists it is convenient to use the AMQP type
> system, however in retrospect it may have been better to simply offer a
> single mechanism of opaque binary and then define a sensible MIME type for
> this content (which is effectively what previous versions of the protocol
> did, though without formally registering those mime types).
> All I'm arguing is that for a given message you should use one encoding
> style only, and that one shouldn't assume that the content-type /
> content-encoding will be any more visible to the end user than the
> descriptor of a described type.
> -- Rob
> >
> > Frase
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message