Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of fraser.adams@blueyonder.co.uk
 designates 80.0.253.69 as permitted sender)
Message-ID: <54109E62.3060701@blueyonder.co.uk>
Date: Wed, 10 Sep 2014 19:54:26 +0100
From: Fraser Adams <fraser.adams@blueyonder.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: AMQP 1.0 Message Encoding - using AMQP typed data vs. Mime
 content-type
 / content-encoding (Was (unintentionally I assume): P)
References: 
 <CACsaS95EKivd7eZdvKNSQTpmp=2+rSNsZuYkKXUtKMP9zx8Cfw@mail.gmail.com>
In-Reply-To: 
 <CACsaS95EKivd7eZdvKNSQTpmp=2+rSNsZuYkKXUtKMP9zx8Cfw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org