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

On 11/02/2010 01:30 PM, James Robinson wrote:
> On Tue, Nov 2, 2010 at 1:04 PM, David Flanagan <david@davidflanagan.com
> <mailto: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 :)

Except that the first argument to open would be unused, and the notion 
of request and response headers probably wouldn't fit well.  And for any 
non-trivial protocol, there would probably be fiddly little details that 
didn't map well to the existing API...

>
>     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

I think that having text, binary, and blob modes is the way forward as 
well.  But Boris's point remains. As proposed, the .responseType 
property would be settable from the jQuery beforeSend callback and  web 
developers might actually attempt to do that so they could get binary 
response data in the jQuery success callback.  But what they'd get 
instead is an exception when jQuery accessed responseText internally.

My point is that (if there is no stomach for new types like 
BinaryHttpRequest) you can sidestep this issue by making responseType a 
read-only property that can only be set with a constructor argument. 
(Yes, jQuery does have an XHR factory hook, so developers could screw 
themselves even if this flag is a constructor argument, but that seems 
much, much less likely.)

	David

	David

Received on Tuesday, 2 November 2010 21:55:11 UTC