Re: [XHR2] ArrayBuffer integration

fwiw, specifying up front is what FileReader appears to do:
http://dev.w3.org/2006/webapi/FileAPI/#dfn-filereader

Of course, there are different methods in that case.

dave

On Tue, Sep 28, 2010 at 3:12 PM, Chris Rogers <crogers@google.com> wrote:
> Based on these constraints, it sounds like we either have to live with the
> fact that we'll keep both a binary copy and a text copy around as we're
> receiving XHR bytes.  Or, we need a way to specify up-front that we're
> interested in loading as binary (before calling send()) and not handle
> binary in the default case.
> Chris
> On Tue, Sep 28, 2010 at 12:05 PM, James Robinson <jamesr@google.com> wrote:
>>
>> On Tue, Sep 28, 2010 at 9:39 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>>
>>> On 9/28/10 10:32 AM, Chris Marrin wrote:
>>>>
>>>> I'd hate the idea of another flag in XHR. Why not just keep the raw bits
>>>> and then convert when responseText is called? The only disadvantage of this
>>>> is when the author makes multiple calls to responseText and I would not
>>>> think that is a very common use case.
>>>
>>> It's actually reasonably common; Gecko had some performance bugs filed on
>>> us until we started caching the responseText (before that we did exactly
>>> what you just suggested).
>>>
>>> Oh, and some sites poll responseText from progress events for reasons I
>>> can't fathom.
>>
>> A number of sites check .responseText.length on every progress event in
>> order to monitor how much data has been received.  This came up as a
>> performance hotspot when I was profiling WebKit's XHR implementation as
>> well.
>> - James
>>
>>>
>>> -Boris
>>>
>>
>
>

Received on Wednesday, 29 September 2010 00:59:46 UTC