W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 28 Oct 2010 21:24:03 -0400
Message-ID: <4CCA2233.8060800@mit.edu>
To: David Flanagan <david@davidflanagan.com>
CC: public-webapps@w3.org
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.

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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:28 UTC