- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 28 Sep 2010 08:37:30 -0400
- 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. -Boris
Received on Tuesday, 28 September 2010 12:38:07 UTC