A few weeks ago I brought up the idea of implementing the responseArrayBuffer attribute for XHR:<div><a href="http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsearraybuffer-attribute">http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsearraybuffer-attribute</a></div>
<div><br></div><div>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&#39;s being built up.  One possible solution which I&#39;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&#39;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&#39;s completely loaded.  Then an access to responseArrayBuffer can easily convert the raw bytes to an ArrayBuffer.</div>
<div><br></div><div>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).</div><div>Conversely, once responseArrayBuffer is accessed, then it would no longer be possible to use responseText or responseXML (an exception would be thrown).</div>
<meta charset="utf-8"><div>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.</div>
<div><br></div><div>How does this sound as an approach?</div><div><br></div><div>Chris</div><div><br></div><div><br></div>