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

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

Received on Friday, 29 October 2010 05:56:35 UTC