W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: David Flanagan <david@davidflanagan.com>
Date: Tue, 02 Nov 2010 13:04:56 -0700
Message-ID: <4CD06EE8.50006@davidflanagan.com>
To: public-webapps@w3.org
CC: Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>, Maciej Stachowiak <mjs@apple.com>, Geoffrey Garen <ggaren@apple.com>, Darin Fisher <darin@chromium.org>, Chris Rogers <crogers@google.com>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Alexey Proskuryakov <ap@webkit.org>, jorlow@google.com, jamesr@chromium.org
Is this a fair summary of this thread?

Chris (Apple) worries that having to support both responseText and 
responseArrayBuffer will be memory inefficient because implementations 
will end up with both representations in memory.

James (Google) worries that synchronously reading bytes from the browser 
cache on demand when responseArrayBuffer is accessed will be too 

Boris (Mozilla) worries that creating a new mode in which responseText 
is unavailable will break jQuery applications.

I've suggested on another thread that the way around this is to abandon 
XHR as a legacy API and create a new HTTPRequest object or 
BinaryHTTPRequest or StreamingHTTPRequest or something.

It occurs to me now, however, that the way to avoid breaking jQuery is 
to make responseType a constructor argument instead of a property to be 
set before send().  If I recall correctly, jQuery always creates its own 
XHR object, so if responseType is only settable at creation time, then 
the situation Boris fears won't arise.  At least not with that library.

Received on Tuesday, 2 November 2010 20:06:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC