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] > >
