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
idiom).
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 :-(
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
