W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: [FileAPI] Deterministic release of Blob proposal

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 05 Mar 2012 17:04:14 -0800
Message-ID: <4F55628E.2040704@jumis.com>
To: Glenn Maynard <glenn@zewt.org>
CC: Feras Moussa <ferasm@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Adrian Bateman <adrianba@microsoft.com>
On 3/5/2012 3:59 PM, Glenn Maynard wrote:
> On Fri, Mar 2, 2012 at 6:54 PM, Feras Moussa <ferasm@microsoft.com 
> <mailto:ferasm@microsoft.com>> wrote:
>
>     To address this issue, we propose that a close method be added to
>     the Blob
>
>     interface.
>
>     When called, the close method should release the underlying
>     resource of the
>
>     Blob, and future operations on the Blob will return a new error, a
>     ClosedError.
>
>     This allows an application to signal when it's finished using the
>     Blob.
>
>
> This is exactly like the "neuter" concept, defined at 
> http://dev.w3.org/html5/spec/common-dom-interfaces.html#transferable-objects.  
> I recommend using it.  Make Blob a Transferable, and have close() 
> neuter the object.  The rest of this wouldn't change much, except 
> you'd say "if the object has been neutered" (or "has the neutered flag 
> set", or however it's defined) instead of "if the close method has 
> been called".
>
> Originally, I think it was assumed that Blobs don't need to be 
> Transferable, because they're immutable, which means you don't 
> (necessarily) need to make a copy when transferring them between 
> threads.  That was only considering the cost of copying the Blob, 
> though, not the costs of delayed GC that you're talking about here, so 
> I think transferable Blobs do make sense.
>
> Also, the close() method should probably go on Transferable (with a 
> name less likely to clash, eg. "neuter"), instead of as a one-off on 
> Blob.  If it's useful for Blob, it's probably useful for ArrayBuffer 
> and all other future Transferables as well.
>

Glenn,

Do you see old behavior working something like the following?

var blob = new Blob("my new big blob");
var keepBlob = blob.slice();
destination.postMessage(blob, '*', [blob]); // is try/catch needed here?
blob = keepBlob; // keeping a copy of my blob still in thread.

Sorry to cover too many angles: if Blob is Transferable, then it'll 
neuter; so if we do want a local copy, we'd use slice ahead of time to 
keep it.
And we might have an error on postMessage stashing it in the transfer 
array if it's not a Transferable on an older browser.
The new behavior is pretty easy.
var blob = new Blob("my big blob");
blob.close(); // My blob has been neutered before it could procreate.

-Charles
Received on Tuesday, 6 March 2012 01:04:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT