W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 27 Oct 2010 03:50:36 -0400
Message-ID: <4CC7D9CC.9000008@mit.edu>
To: Boris Zbarsky <bzbarsky@mit.edu>
CC: Darin Fisher <darin@chromium.org>, Chris Rogers <crogers@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Alexey Proskuryakov <ap@webkit.org>, Chris Marrin <cmarrin@apple.com>, Geoffrey Garen <ggaren@apple.com>, jorlow@google.com, jamesr@chromium.org
On 10/27/10 3:40 AM, Boris Zbarsky wrote:
> On 10/27/10 3:24 AM, Darin Fisher wrote:
>> So, it sounds like we just need to present you with some concrete
>> examples of XHRs being used to fetch large responses as Text or XML, and
>> then you will be convinced?
>
> Uh... no. I'm sure these happen. The question is whether their existence
> is sufficient grounds to impose additional burdens on other uses of XHR.

And specifically for the case you cited (large XML file that you process 
via XML) Webkit is already storing two copies of the data: the 
responseText and the parsed DOM.  I'd be very surprised if the latter is 
much smaller in terms of memory used, and somewhat surprised if it's 
smaller at all.

So for this specific use case, in fact, if you just stored the raw bytes 
and the parsed DOM you would be no worse off than you are now (and this 
is in fact what Gecko does in this situation).

The double storage issue really only comes up for cases when 
responseText is being used, not responseXML, as far as I can tell.

-Boris
Received on Wednesday, 27 October 2010 07:51:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT