Sorry I missed this one,
Comments inline.
On 10/09/14 18:08, Rob Godfrey wrote:
I think it's inconsistent to use a mechanism (content type) intended for
opaque data on data which is not opaque... only in a couple of special
cases (an amqp-value section containing a string or binary value) does it
make sense.
Hmm I could interpret opacity in a number of ways. For example the data
that we are talking about is JSON, now that happens to be using a String
as a container format but the fact that it is JSON is *entirely opaque*
to the AMQP type system hence why IMHO it entirely makes sense to pass
additional metadata to detail how it should be interpreted.
Now described might be OK, but I assert that following common design
patterns is a very good idea and the pattern that I suspect 99 per cent
of the population would instinctively choose would be the pattern
employed by HTTP.
In general the question is who is the field aimed at - the
AMQP library or the client application? I think the content-type should
actually be interpreted by the AMQP library - in the same way that I would
expect the AMQP types to be.
I'd probably have assumed it would be more the client application, but
no matter I think that if you expect the AMQP library you actually
strengthen my argument. If I want to do what I've suggested I can have
my JavaScript library take a JavaScript object, set the content-type and
use that to tell the recipient how to deserialise it transparently
passing a JavaScript Object to the consumer client.
That's fine and grand except that you seem to be telling me that
content-type can't actually be used to do *anything useful*!!!
I think it "appears" to be more convenient to set the content-type on the
properties field for a string value because we perceive that the client
library would be able to understand AmqpValue(String("{ }")) but not
AmqpValue(Described(Symbol("org.json"),String("{ }"))) and that the
content-type would be made available to the end user of the API for them to
then be able to understand that this is Json, and not intercepted by the
client library.
No what I'm saying is that it "appears" to be more convenient because
there's about half a billion AJAX based web-pages that set
content-type=application/json and send the JSON string in the HTTP
Message Body.
As it happens my JavaScript Library can do this fairly trivially with
message.body = new proton.Data.Described({"some": "json"},
'application/json');
And it's roughly as easy to add some code to the serialisation of
Described to call toJSON() when it encounters a descriptor of
"application/json" as it would be to add something around content-type
(though other APIs might have more fun :-)) but although in
implementation terms it's roughly as easy it seems an awful lot weirder
and less intuitive than
message.setContentType('application/json');
message.body = {"some": "json"};
However that's not necessarily the case (the current JMS
client doesn't expose the content type IIRC, and may use it for switching
behaviours on opaque data - e.g. for object messages).
That's a reasonable point, though in that case I'd suggest that the
content type should be an extension type "application/x-amqp-map" and
shouldn't be interfering with any IANA registered content types.
More generally I think we collectively (in Qpid and in the wider AMQP
world) need to decide when/if we use the AMQP type system to encode data,
versus using MIME types.
For the most part I'm fairly happy with the AMQP type system, though I
can recall Gordon and Rafi had quite an exciting debate about the
relative merits of JSON versus the AMQP type system.
I wasn't specifically looking to rekindle that in this discussion, this
was more about using content-type in a manner that I would assert the
*vast majority* of the broader technical community would intuitively
expect it to be used.
If I want to start compressing data as I generally send large messages,
should I send my data with the content-encoding as gzip, or should I define
a new described type for compressed data. If the former - what if the
large message I want to send is a map?
well I think that I'd probably follow an Internet style pattern along
the lines of:
message.setContentType('application/x-amqp-map');
message.setContentEncoding('gzip');
My general advice is to choose one mechanism or the other and not to
confuse the two.
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.
The spec is the spec, and now ratified at ISO, so the wording there is not
going to change. We could interpret the spec more loosely, but - as above
- i think that ultimately that will lead to more confusion.
-- Rob
Yes the spec is the spec, but in my opening paragraph I asserted that
opacity is in the eye of the beer-holder and the fact that this stuff is
JSON is very definitely opaque from the perspective of AMQP in the
scenarion that I've been describing.
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
