There's been some recent discussion in the webkit-dev mailing list about the efficiency of implementation of the "responseArrayBuffer" attribute. People are concerned that it would require keeping two copies of the data around (raw bytes, and unicode text version) since it's unknown up-front whether "responseText", or "responseArrayBuffer" will be accessed. I have a few possible solutions to this problem:
1. 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. 2. Darin Fisher has suggested this approach: Add an "asArrayBuffer" attribute (similar to "asBlob") which *must* be set before sending the request if there will be a subsequent access of the "responseArrayBuffer" attribute. 3. Get rid of the "asBlob" attribute and add a new "responseType" attribute which could be: "Text" <--- this is the default "XML" "Bytes" ... other types yet to be defined Approach (2) can lead to illegal combinations (both asBlob and asArrayBuffer set to true), but approach (3) is not as discoverable at runtime as (2), because (2) allows for the simple existence check of either attribute "asBlob" or "asArrayBuffer". I can accept any of the proposed solutions and would like to hear what others think about these or other approaches. Chris
