Re: File API: closed Blob objects

On Dec 12, 2013, at 10:07 AM, Anne van Kesteren wrote:

> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=24072 for context.
> 
> What's the use case for close()?


Essentially, the use case is for web developers to be able to flush a Blob reference that isn't used, allowing the user agent to manage resources.

This was expressed in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16952#c2



> 
> If we are to have close(), let's define it in such a way that once you
> invoke it the Blob represents the empty byte sequence. This way other
> code that takes and operates on Blob objects does not have to special
> case closed Blob objects, but can just treat them as Blob objects that
> happen to be empty.


Currently, we say that :

"Calling the close method on a Blob must disable it such that it cannot be used again; dereferencing a blob: URL bound to a Blob object on which close() has been called results in a network error. A Blob on which close() has been called must have a size of 0. This must be an irreversible and non-idempotent operation; once close() has been called on a Blob, that Blob cannot be used again."

Is "size of 0" a sufficient constraint? I'm inclined to think so, and that we already support your suggestion.

Also, note that neutering a transferable object and calling close on Blob are *different things.*  We can make Blob's size 0 on close().  But, neutering a transferable object should throw on subsequent access.  You'll recall that we forced them to be different things based on bugs such as:

1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=18611 and
2. https://www.w3.org/Bugs/Public/show_bug.cgi?id=23416

-- A*



-- A*