On 10/28/2010 06:24 PM, Boris Zbarsky wrote:
On 10/28/10 5:22 PM, David Flanagan wrote:
In fact, I'd go further and ask why the blob case needs to be special
cased at all. The bytes are stored somewhere. Returning them as a blob
doesn't seem any harder than returning them as an ArrayBuffer.
David, the issue is that if you make a request for a 4GB resource and
ask for it as an array buffer and you're on a 32-bit system, the only
thing the browser can do is throw an out of memory exception.
On the other hand, if you access the same response as a blob, the
browser can let you do that; you just won't be able to get it all into a
single JS string.
Thanks for the explanation, Boris. The L in Blob is an order of
magnitude larger than anything I was imagining. Now I understand why
both Blobs and ArrayBuffer are required. I still don't get, however, why
the API needs distinct blob/non-blob modes. Why not do it like this:
- The implementation decides whether to store the response in a file or
not based on its own knowledge of the Content-Length and of the system's
hardware. (And perhaps the developer can set some kind of reallyBig
flag as a hint that the implementation should consider saving the
response to disk.)
- The response body is always available through responseBlob. No special
asBlob flag is required.
- If the response is too big to fit in memory, then accessing
responseText, responseArrayBuffer or responseXML will throw an
out-of-memory exception. This is what would happen if you naively tried
to use the FileReader interface on the un-sliced Blob, so why can't that
happen here?
With the API as it is now, a web developer who wants to download a
gigantic chunk of data has to know in advance to use a blob to avoid the
possibility of out-of-memory errors. They have to put their XHR object
into a special asBlob mode in order to do so. And once they ar in that
mode if they try to use responseText or responseArrayBuffer, they're
guaranteed to get a INVALID_STATE_ERR exception at runtime.
With my proposal, the developer still has to know in advance that they
probably ought to use a blob. But they don't have to set a special flag
to do it. And if they do use responseText or responseArrayBuffer, they
might get an out-of-memory error at runtime, but there's also a decent
chance that things will just work (maybe with some disk swapping slowing
things down a bit).
I doubt I understand all the implementation issues. But if there really
is some reason to have this blob/non-blob decision point before calling
send(), can I suggest that instead of confusing the XHR API with it, it
be moved into a separate BlobHttpRequest interface that has only
reponseBlob and does not even define responseText, etc.
David
