qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Use of content-type in AMQP 1.0
Date Wed, 10 Sep 2014 18:10:14 GMT
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.

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 

TBH IMHO anything other that content-type=application/json with the body 
being a string containing the JSON seems downright weird to me :-)

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 :-(


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

View raw message