- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 28 Sep 2010 14:09:34 +0200
- To: "Web Applications Working Group WG" <public-webapps@w3.org>, "Michael Nordman" <michaeln@google.com>
- Cc: "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 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. Considering the > overwhelming number of responseText only use cases, it would be nice to > not incur extra costs to support a new binary accessor which would be > rarely used compared to the text accessor. So some way of making these > mutually exclusive in the API. I was a bit wary already with responseBlob, but should we really punt all the complexity to authors? 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. > Should we have an asArrayBuffer attribute (or similar) to tell XHR up > front how the caller wishes to access the response? > > Or maybe specify the accessors such that when you use responseText you > can not later access responseArrayBuffer and vice versa? > > Are there any use cases where you'd need it both ways? 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. -- Anne van Kesteren http://annevankesteren.nl/
Received on Tuesday, 28 September 2010 12:10:23 UTC