Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

On Mon, Oct 25, 2010 at 3:21 PM, Chris Rogers <crogers@google.com> wrote:

> There's been some recent discussion in the webkit-dev mailing list about
> the efficiency of implementation of the "responseArrayBuffer" attribute.
>  People are concerned that it would require keeping two copies of the data
> around (raw bytes, and unicode text version) since it's unknown up-front
> whether "responseText", or "responseArrayBuffer" will be accessed.  I have a
> few possible solutions to this problem:
>
> 1.  Defer decoding the text, and instead buffer the raw data as it comes
> in.  If there's any access to responseText (or responseXML), then the
> buffered data can be decoded into text at that time, and the buffered raw
> data discarded.  If that case happens, then from that point on no raw data
> buffering would happen and the text would be accumulated as it is right now.
>  Otherwise, if responseText is never accessed then the raw data continues to
> buffer until it's completely loaded.  Then an access to responseArrayBuffer
> can easily convert the raw bytes to an ArrayBuffer.
>
> The idea is that once responseText or responseXML is accessed, then it
> would no longer be possible to access responseArrayBuffer (an exception
> would be thrown).
> Conversely, once responseArrayBuffer is accessed, then it would no longer
> be possible to use responseText or responseXML (an exception would be
> thrown).
> This approach does seem a little strange because of the mutually exclusive
> nature of the access.  However, it seems that it would be hard to come up
> for a reasonable use case where both the raw bytes *and* the text would be
> needed for the same XHR.
>
> 2. Darin Fisher has suggested this approach: Add an "asArrayBuffer"
> attribute (similar to "asBlob") which *must* be set before sending the
> request if there will be a subsequent access of the "responseArrayBuffer"
> attribute.
>
> 3. Get rid of the "asBlob" attribute and add a new "responseType" attribute
> which could be:
> "Text"   <--- this is the default
> "XML"
>  "Bytes"
> ... other types yet to be defined
>
> Approach (2) can lead to illegal combinations (both asBlob and
> asArrayBuffer set to true), but approach (3) is not as discoverable at
> runtime as (2), because (2) allows for the simple existence check of either
> attribute "asBlob" or "asArrayBuffer".
>
> It's certainly easy to check for illegal combinations on send, or for that
matter disallow setting more than one of them in the first place.

Also, 3 allows for a simple existence check as well.

I can accept any of the proposed solutions and would like to hear what
> others think about these or other approaches.
>
> Chris
>
>