W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: James Robinson <jamesr@google.com>
Date: Tue, 2 Nov 2010 13:30:17 -0700
Message-ID: <AANLkTikoFZ1+Ss51Q87D1=_p4uDbU-2mq_8OFgsAEuhy@mail.gmail.com>
To: David Flanagan <david@davidflanagan.com>
Cc: public-webapps@w3.org, 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
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
Received on Tuesday, 2 November 2010 20:30:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC