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
