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

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.

So there are definitely use cases for being able to access as a Blob.

> I know that Blobs are an outgrowth of the File API, but won't many Blobs
> (created by BlobBuilders, for example) be in-memory objects rather than
> on-disk objects?

I believe BlobBuilder can stick the data anywhere it wants.

> And shouldn't the decision about whether to spool a
> response to disk or not be implementation-dependent?

It is, yes.  But we still need an API that doesn't force the response 
into memory in its entirety.

> and then memory map it
> to make it look like it is in memory.

That doesn't help for the truly large responses; the OS won't let you 
memory map them in its entirety...

> (Probably because I'm missing something fundamental about the nature of
> Blobs... I'd love to know what it is!)

The key part with a blob is that you can access parts of it without 
forcing the whole thing into the process's address space.

-Boris

Received on Friday, 29 October 2010 01:24:39 UTC