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.
Regards Jakub On Wed, Sep 10, 2014 at 8:50 PM, Rob Godfrey <[email protected]> wrote: > On 10 September 2014 20:10, Fraser Adams <[email protected]> > 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
