- From: David Flanagan <david@davidflanagan.com>
- Date: Wed, 03 Nov 2010 10:47:24 -0700
- 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 UTC