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

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