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

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

From: David Flanagan <david@davidflanagan.com>
Date: Wed, 03 Nov 2010 10:47:24 -0700
Message-ID: <4CD1A02C.7030901@davidflanagan.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: public-webapps@w3.org, Jonas Sicking <jonas@sicking.cc>, 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, jamesr@chromium.org
On 11/02/2010 07:06 PM, Boris Zbarsky wrote:
> On 11/2/10 4:04 PM, David Flanagan wrote:
>> Boris (Mozilla) worries that creating a new mode in which responseText
>> is unavailable will break jQuery applications.
>
> And various others where the consumer of the data and the XHR creator
> are not the same entity. jQuery is just an obvious example that we all
> know about, is public, and clearly illustrates the pattern....
>
>> 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.
>
> That last sentence is key there... ;)
>
> -Boris
>
So if making responseType a constructor argument isn't enough to rescue 
the XHR API, that brings me back to my preferred solution: a new 
BinaryHttpRequest API.

I think everyone on this thread has agreed that ease of use for web 
developers is more important than ease for implementors.

As someone who documents stuff like this for web developers, I think 
I've got a pretty good handle on what is easy to use and what is not 
(documentation ease maps well to coding ease).

So in my professional capacity I argue that having a separate new 
BinaryHttpRequest API would be conceptually simpler and easier for 
developers than having a single XMLHttpRequest object with both a legacy 
responseText property and a new response property and with properties 
like responseType or asBlob that put the object into special modes.

It would also be easier to document a new binary API than it would be to 
document the optimization hints for the current API: "be careful to not 
access both responseText and responseArrayBuffer because that may cause 
extra memory usage, although on some implementations that extra memory 
is going to be allocated no matter what you do".

    David
Received on Wednesday, 3 November 2010 17:48:00 GMT

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