On 9/28/10 8:09 AM, Anne van Kesteren wrote:
On Tue, 28 Sep 2010 03:22:13 +0200, Michael Nordman
<[email protected]> 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
