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