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
