Hi David,
Sorry for the delayed response. I think the idea of BinaryHttpRequest is a
reasonable one. As you point out, it simply side-steps any potential
performance and compatibility issues. Are you imagining that the API is
effectively the same as XMLHttpRequest, except without the text and XML
part?
How do other people feel about David's proposal?
Chris
On Wed, Nov 3, 2010 at 10:47 AM, David Flanagan <david@davidflanagan.com>wrote:
> 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
>