- From: David Flanagan <david@davidflanagan.com>
- Date: Fri, 29 Oct 2010 08:12:04 -0700
- To: Anne van Kesteren <annevk@opera.com>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On 10/29/2010 06:07 AM, Anne van Kesteren wrote: > On Fri, 29 Oct 2010 13:08:07 +0200, Anne van Kesteren <annevk@opera.com> > wrote: >> Brainstorming here. We could choose to always expose >> resonseArrayBuffer and keep it together with responseText and >> responseXML. And for applications that are worried about memory usage >> or care about very large files we could have BlobXMLHttpRequest >> similar to AnonXMLHttpRequest. We'd abstract some things out from >> XMLHttpRequest so BlobXMLHttpRequest does not have the other response* >> members and so that AnonXMLHttpRequest does not need withCredentials >> and the fourth and fifth parameter to open(). > > Nevermind, then we'd need AnonBlobXMLHttpRequest too for completeness. > Not so great. > Too bad. If you were okay with BlobHttpRequest and AnonBlobHttpRequest, I was going to propose BufferHttpRequest and AnonBufferHttpRequest as well. If adding a responseType flag would break jQuery, and not adding responseType would double the memory usage of all XHR requests, then it seems like defining a new API is the way out of the dilemma. So if I can continue the brainstorm... Note that a new BufferHttpRequest need not be binary-only. It can still have a decodeResponseAsText() method or something equivalent. And it creates the opportunity to get rid of XML in the name! Why can't the Anon part be taken care of with a constructor parameter? (And is there any value in putting other things in the constructor like a cross-origin flag and the withCredentials flag?) XMLHttpRequest(anon): has today's responseText and responseXML properties only. (Is there a case for anonymous legacy XHR at all?) BufferHttpRequest(anon): has a single response property that is an ArrayBuffer. For convenience, it also has a responseAsText property that decodes the buffer to text when read. (Purposely avoiding "responseText" so legacy code that checks responseText.length can't be ported to BufferHttpRequest) BlobHttpRequest(anon): has a single response property that is a Blob. Of course defining a BufferHttpRequest type really invites a StreamingHttpRequest as well, and I have the suspicion that a streaming API solves a more fundamental problem than Blobs do... David
Received on Friday, 29 October 2010 15:12:40 UTC