The solution for .responseBlob was to add an .asBlob attribute that would need to be set to true before calling .send(). We could do the same for .responseArrayBuffer.
-Darin On Mon, Oct 25, 2010 at 12:17 PM, Geoffrey Garen <[email protected]> wrote: > Hi Chris. > > I like the efficiency of this approach. And I agree with your premise that > a developer will probably only want one type of data (raw, text, or XML) per > request, and not more than one. > > My biggest concern with this idea is that there's nothing obvious about the > API pattern of three properties -- .responseText, .responseXML, and > .responseArrayBuffer -- that makes clear that accessing one should prohibit > access to the others. I wonder if there's a good way to make this clearer. > > Maybe the API should require the programmer to specify in advance what type > of data he/she will ask for. For example, an extra responeType parameter > passed to open. The default behavior would be the values currently > supported, but you could opt into something specific for extra > safety/performance, and new types of data: > > request.open("GET", "data.xml", true, "Text"); > request.open("GET", "data.xml", true, "XML"); > request.open("GET", "data.xml", true, "Bytes"); > > Geoff > > > > On Oct 22, 2010, at 4:47 PM, Chris Rogers wrote: > > A few weeks ago I brought up the idea of implementing the > responseArrayBuffer attribute for XHR: > > http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsearraybuffer-attribute > > One of the concerns was that it might require double the memory usage since > the raw bytes would have to be accumulated along with the decoded text as > it's being built up. One possible solution which I've been discussing with > James Robinson and Ken Russell is to defer decoding the text, and instead > buffer the raw data as it comes in. If there's any access to responseText > (or responseXML), then the buffered data can be decoded into text at that > time, and the buffered raw data discarded. If that case happens, then from > that point on no raw data buffering would happen and the text would be > accumulated as it is right now. Otherwise, if responseText is never > accessed then the raw data continues to buffer until it's completely loaded. > Then an access to responseArrayBuffer can easily convert the raw bytes to > an ArrayBuffer. > > The idea is that once responseText or responseXML is accessed, then it > would no longer be possible to access responseArrayBuffer (an exception > would be thrown). > Conversely, once responseArrayBuffer is accessed, then it would no longer > be possible to use responseText or responseXML (an exception would be > thrown). > This approach does seem a little strange because of the mutually exclusive > nature of the access. However, it seems that it would be hard to come up > for a reasonable use case where both the raw bytes *and* the text would be > needed for the same XHR. > > How does this sound as an approach? > > Chris > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
