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

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 30 Oct 2010 01:43:33 -0400
Message-ID: <4CCBB085.80305@mit.edu>
To: Jonas Sicking <jonas@sicking.cc>
CC: Maciej Stachowiak <mjs@apple.com>, Geoffrey Garen <ggaren@apple.com>, Darin Fisher <darin@chromium.org>, Chris Rogers <crogers@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Alexey Proskuryakov <ap@webkit.org>, Chris Marrin <cmarrin@apple.com>, jorlow@google.com, jamesr@chromium.org
On 10/28/10 11:29 PM, Jonas Sicking wrote:
> Personally I like the proposed responseType solution.

The one where you pick one up front and it throws if you ask for 
something else, right?

> I agree that it has a downside in that it doesn't allow figuring out
> the type as data starts coming in.

Well, that, and the whole "throws exceptions" bit...

> However I think this is a much less
> common case then knowing the type before the request is made.

I agree that far, yes.

> I do think that supporting the case of downloading something which
> type you don't know is a use-case that we need to support. But I don't
> think that the way to do that is to have XHR parse things into every
> conceivable format at the same time.

I'm not suggesting it do that.

> I also am not a big fan of the
> lazy-decode-into-whatever-format-users-want. It makes it much too easy
> for a site to use up more memory and CPU than it needs.

As opposed to having sites decode themselves?  I'm not sure there's much 
difference.

> For users that can handle
> progressive handling of the downloaded content, keeping all the
> so-far-downloaded data in memory is pure waste.

Sure.  The question is how to make their lives better without making 
others' lives worse (or at least too much worse?).

> (To make matters worse, we don't just keep all the data in memory, but for each
> additional downloaded piece of content, we over and over reallocate a
> ever-expanding block of memory.

That seems like an implementation detail.  Nothing is really preventing 
segmented storage of the data (not even the responseArrayBuffer getter, 
if it were added).

> For the case when it's known what type of response is expected this
> seems to work very well.

As long as only one entity is doing the expecting, right?  Right now 
jquery expects to get responseText, so if you expect something else you 
can't use jquery's XHR wrappers, say....

> For the case when looking at the response body is required to
> determine how the response should be handled I'm less sure. One
> solution would be to say that people can just use .responseType =
> "binary" or .responseType = "blob" and then do the processing
> themselves.

This actually seems ok to me if we have APIs for doing that.  Seems like 
an excellent idea, in fact.

Again, my concern is that the exception-throwing behavior is 
error-prone, and worse yet that we have existing uses of the API that 
make certain assumptions that the behavior will break.  If this were a 
brand-new API I could perhaps be convinced to do the exception thing, 
since that's just how it would be.  I'm really worried about deploying 
that sort of thing into the existing environment, though.

-Boris
Received on Saturday, 30 October 2010 05:44:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT