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
