W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [XHR2] ArrayBuffer integration

From: Chris Rogers <crogers@google.com>
Date: Tue, 28 Sep 2010 15:12:46 -0700
Message-ID: <AANLkTikRvPd19rP8yqfVQjMb32dNiViTauGf2sHj6b9S@mail.gmail.com>
To: James Robinson <jamesr@google.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Chris Marrin <cmarrin@apple.com>, Michael Nordman <michaeln@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Jian Li <jianli@chromium.org>, Anne van Kesteren <annevk@opera.com>, Julian Reschke <julian.reschke@gmx.de>, Kenneth Russell <kbr@google.com>, Vladimir Vukicevic <vladimir@mozilla.com>
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.


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 Tuesday, 28 September 2010 22:13:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC