Re: [XHR2] why have an asBlob attribute at all?

On 10/29/2010 06:07 AM, Anne van Kesteren wrote:
 > On Fri, 29 Oct 2010 13:08:07 +0200, Anne van Kesteren <>
 > 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...


Received on Friday, 29 October 2010 15:12:40 UTC