Re: [FileAPI] Deterministic release of Blob proposal

(I wish people wouldn't split threads.)

On Tue, Mar 6, 2012 at 2:29 PM, Eric U <ericu@google.com> wrote:

> What about:
>
>        XHR.send(blob);
>        blob.close();
>

This is the same as:

XHR.send(arrayBuffer);
postMessage({foo: arrayBuffer}, [arrayBuffer]);

which you can already do.  Both of these should always work, because send()
synchronously makes a (logical) copy of the underlying data:

If data is a ArrayBuffer
    Let the request entity body be the raw data represented by data.
If data is a Blob
    Let the request entity body be the raw data represented by data.

which happens before the call returns.


> or
>
>        iframe.src = createObjectURL(blob);
>        blob.close();
>
In the second example, if we say that the iframe does copy the blob,
> does that mean that closing the blob doesn't automatically revoke the
> URL, since it points at the new copy?  Or does it point at the old
> copy and fail?


Looking at this without involving iframe:

You could define object URLs as references to a new copy of the blob.  That
would mean that if the blob is neutered while object URLs still point at
it, a copy of the blob would have to be made by the UA even though it's
transferred.

Or, object URLs could be references to the blob itself.  That means that if
the blob is neutered, existing object URLs would be implicitly revoked.

I'd suggest the former: when a Blob is passed to native APIs, make a
(logical) copy of the Blob.  More generally, I'd recommend that all native
calls which accept a Blob, like createObjectURL, make a logical copy of the
data, like XHR.send does.  It's much easier to be consistent that way.


On Tue, Mar 6, 2012 at 3:27 PM, Arun Ranganathan <aranganathan@mozilla.com>
 wrote:

> although this creates something to think about for MessagePort and for
> ArrayBuffer, which also implement Transferable).
>

close() would be useful for ArrayBuffer, too.  It's not obviously useful
for MessagePort, but doesn't seem harmful for it to inherit it if it's not
a big implementation burden.  That's better than every single
implementation of Transferable having to define this itself.

-- 
Glenn Maynard