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

Re: [XHR2] ArrayBuffer integration

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 28 Sep 2010 08:37:30 -0400
Message-ID: <4CA1E18A.1010707@mit.edu>
To: Anne van Kesteren <annevk@opera.com>
CC: Web Applications Working Group WG <public-webapps@w3.org>, Michael Nordman <michaeln@google.com>, Jian Li <jianli@chromium.org>, Julian Reschke <julian.reschke@gmx.de>, Chris Marrin <cmarrin@apple.com>, Kenneth Russell <kbr@google.com>, Vladimir Vukicevic <vladimir@mozilla.com>, Chris Rogers <crogers@google.com>
On 9/28/10 8:09 AM, Anne van Kesteren wrote:
> On Tue, 28 Sep 2010 03:22:13 +0200, Michael Nordman
> <michaeln@google.com> wrote:
>> A couple of us have been looking at webkit's XHR impl and realized
>> that to support performant access to the response via
>> responseArrayBuffer and
>> responseText would cause us to keep two copies of the data around, a raw
>> data buffer and the second decoded text buffer.

For what it's worth, Gecko does this.  It's needed anyway to support 
responseText read during the load (which does happen on the web), since 
the relevant charset can change as the document is parsed, last I 
checked....  It kinda sucks but there it is.

In practice, we handle this by lazily generating responseText on demand.

> On top of that, how should overrideMimeType be designed if not the way
> it is currently in the specification. As now it effectively requires
> keeping the raw octets around.

Yep.  I don't see this as a problem, fwiw.

> I'm not sure. But you could just lazily construct the data based on what
> the author requests. If there are no use cases it is unlikely they will
> use both.

You can't lazily construct the original byte stream from the 
responseText, fwiw.  So I'm not quite following how that paragraph would 
address Michael's concerns.

Received on Tuesday, 28 September 2010 12:38:07 UTC

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