On Tue, Nov 2, 2010 at 1:04 PM, David Flanagan <david@davidflanagan.com>wrote:
> 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.
>
>
There were two Chrises on the discussion - Rogers (Google) and Marrin
(Apple) - if anyone is keeping tabs.
> James (Google) worries that synchronously reading bytes from the browser
> cache on demand when responseArrayBuffer is accessed will be too
> time-inefficient.
>
Not quite - my main concern is the same as Chris' that keeping multiple
representations of the data will lead to bloat. There's a bit more nuance
but people can read the original thread if they want.
>
> 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.
>
If we are getting rid of the XML part we should drop HTTP as well since this
API would also work over non-HTTP protocols :)
>
> 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
>
I like the .responseType proposal for the reasons Jonas stated on the last
thread. That allows legacy content continue to work unchanged (without
extra memory bloat) and lets us extend the API efficiently in the future.
- James