Re: File API: closed Blob objects

On Dec 12, 2013 9:55 AM, "Arun Ranganathan" <arun@mozilla.com> wrote:
>
> 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

Generally it is not good to rely on GC for "very heavy" resources. This is
also why we have Worker.close()

>> 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."

Reading from a Blob that has been closed() is a developer error with high
degree of certainty. Nothing useful can come out of that.

So I think we do the developer a benefit by treating it as such and
signaling an error through whatever mechanism is appropriate depending on
how the reading was done.

We can certainly debate if throwing an exception or if asynchronously
reporting a network error is the right thing to do for things like
XHR.send(closedBlob) or FileReader.readAsX(closedBlob).

/ Jonas