Re: [FileAPI] Deterministic release of Blob proposal

On Wed, Mar 7, 2012 at 5:58 PM, Feras Moussa <ferasm@microsoft.com> wrote:

> In the case where close was called on a Blob that is being used in a
> pending request, then the request should be canceled. The expected
> result is the same as if abort() was called.
>

This would complicate every API that uses Blobs.  APIs should just make a
copy of the underlying data.  It minimizes the effects on other APIs and
makes the behavior consistently understandable.  In the case of XHR2, the
only change you'd need to make to that API, I think, would be for send() to
say "if *data* is a *neutered* object, throw an exception" in step 3 of
send().  The rest is already dealt with, since XHR2 already makes a copy
("Let the request entity body be the raw data represented by data.").

It simply means that any time you pass a Blob to a native API, the Blob is
implicitly sliced to create an independent (shallow, of course) copy before
it's used or stashed for later use.

That way, APIs never have to deal with blobs being released out from
underneath them, which could complicate things significantly (eg. you might
be accessing the blob's data from an asynchronous section).

> var a = new Image();
> > a.onerror = function() { console.log("Oh no, my parent was neutered!");
> }; a.src = URL.createObjectURL(blob); blob.close();
> >
> > Is that error going to hit?
> I documented this in my proposal, but in this case the URI would have
> been minted prior to calling close. The Blob URI would still resolve
> until it has been revoked, so in your example onerror would not be hit
> due to calling close.
>

I do think this is what should happen, because createObjectURL would create
a copy of blob.  It seems a bit inconsistent with what your proposal,
though (if blob.close() always releases the underlying data, to the point
of aborting asynchronous XHR, then it should do so if it has associated
URLs, too).

-- 
Glenn Maynard