- From: David Flanagan <david@davidflanagan.com>
- Date: Tue, 02 Nov 2010 13:04:56 -0700
- 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 time-inefficient. 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. David
Received on Tuesday, 2 November 2010 20:06:07 UTC