W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [XHR2] ArrayBuffer integration

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 28 Sep 2010 14:09:34 +0200
To: "Web Applications Working Group WG" <public-webapps@w3.org>, "Michael Nordman" <michaeln@google.com>
Cc: "Jian Li" <jianli@chromium.org>, "Julian Reschke" <julian.reschke@gmx.de>, "Chris Marrin" <cmarrin@apple.com>, "Kenneth Russell" <kbr@google.com>, "Vladimir Vukicevic" <vladimir@mozilla.com>, "Chris Rogers" <crogers@google.com>
Message-ID: <op.vjqr17x364w2qv@anne-van-kesterens-macbook-pro.local>
On Tue, 28 Sep 2010 03:22:13 +0200, Michael Nordman <michaeln@google.com>  
> A couple of us have been looking at webkit's XHR impl and realized that  
> to support performant access to the response via responseArrayBuffer and
> responseText would cause us to keep two copies of the data around, a raw
> data buffer and the second decoded text buffer. Considering the  
> overwhelming number of responseText only use cases, it would be nice to  
> not incur extra costs to support a new binary accessor which would be  
> rarely used compared to the text accessor. So some way of making these  
> mutually exclusive in the API.

I was a bit wary already with responseBlob, but should we really punt all  
the complexity to authors?

On top of that, how should overrideMimeType be designed if not the way it  
is currently in the specification. As now it effectively requires keeping  
the raw octets around.

> Should we have an asArrayBuffer attribute (or similar) to tell XHR up  
> front how the caller wishes to access the response?
> Or maybe specify the accessors such that when you use responseText you  
> can not later access responseArrayBuffer and vice versa?
> Are there any use cases where you'd need it both ways?

I'm not sure. But you could just lazily construct the data based on what  
the author requests. If there are no use cases it is unlikely they will  
use both.

Anne van Kesteren
Received on Tuesday, 28 September 2010 12:10:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:27 UTC