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

RE: [FileAPI] Deterministic release of Blob proposal

From: Feras Moussa <ferasm@microsoft.com>
Date: Wed, 7 Mar 2012 01:12:39 +0000
To: Arun Ranganathan <aranganathan@mozilla.com>
CC: Adrian Bateman <adrianba@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>
Message-ID: <1BF800349B6CDF4C82313F8D9EF3239D03E084D6@TK5EX14MBXC273.redmond.corp.microsoft.com>
> From: Arun Ranganathan [mailto:aranganathan@mozilla.com] 
> Sent: Tuesday, March 06, 2012 1:27 PM
> To: Feras Moussa
> Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson; Anne van Kesteren
> Subject: Re: [FileAPI] Deterministic release of Blob proposal
> Feras,
> In practice, I think this is important enough and manageable enough to include in the spec., and I'm willing to slow the train down if necessary, but I'd like to understand a few things first.  Below:
> ________________________________________
> > At TPAC we discussed the ability to deterministically close blobs with a few 
> > others.
 > >
> > As we’ve discussed in the createObjectURL thread[1], a Blob may represent 
> > an expensive resource (eg. expensive in terms of memory, battery, or disk 
> > space). At present there is no way for an application to deterministically 
> > release the resource backing the Blob. Instead, an application must rely on 
> > the resource being cleaned up through a non-deterministic garbage collector 
> > once all references have been released. We have found that not having a way 
> > to deterministically release the resource causes a performance impact for a 
> > certain class of applications, and is especially important for mobile applications 
> > or devices with more limited resources.
> > 
> > In particular, we’ve seen this become a problem for media intensive applications 
> > which interact with a large number of expensive blobs. For example, a gallery 
> > application may want to cycle through displaying many large images downloaded 
> > through websockets, and without a deterministic way to immediately release 
> > the reference to each image Blob, can easily begin to consume vast amounts of 
> > resources before the garbage collector is executed. 
 > >
> > 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.
> > 

> Do you agree that Transferable 
> (http://dev.w3.org/html5/spec/Overview.html#transferable-objects) seems to be what 
> we're looking for, and that Blob should implement Transferable?  
> Transferable addresses the use case of copying across threads, and "neuters" the source 
> object (though honestly, the word "neuter" makes me wince -- naming is a problem on the 
> web).  We can have a more generic method on Transferable that serves our purpose here, 
> rather than *.close(), and Blob can avail of that.  This is something we can work out with HTML, 
> and might be the right thing to do for the platform (although this creates something to think 
> about for MessagePort and for ArrayBuffer, which also implement Transferable).
> I agree with your changes, but am confused by some edge cases:
>> To support this change, the following changes in the File API spec are needed:
> >
>> * In section 6 (The Blob Interface)
>>  - Addition of a close method. When called, the close method releases the 
>> underlying resource of the Blob. Close renders the blob invalid, and further 
>> operations such as URL.createObjectURL or the FileReader read methods on 
>> the closed blob will fail and return a ClosedError.  If there are any non-revoked 
>> URLs to the Blob, these URLs will continue to resolve until they have been 
>> revoked. 
>>  - For the slice method, state that the returned Blob is a new Blob with its own 
>> lifetime semantics – calling close on the new Blob is independent of calling close 
>> on the original Blob.
>> *In section 8 (The FIleReader Interface)
>> - State the FileReader reads directly over the given Blob, and not a copy with 
>> an independent lifetime.
>> * In section 10 (Errors and Exceptions)
>> - Addition of a ClosedError. If the File or Blob has had the close method called, 
>> then for asynchronous read methods the error attribute MUST return a 
>> “ClosedError” DOMError and synchronous read methods MUST throw a 
>> ClosedError exception.
>> * In section 11.8 (Creating and Revoking a Blob URI)
>> - For createObjectURL – If this method is called with a closed Blob argument, 
>> then user agents must throw a ClosedError exception.
>> Similarly to how slice() clones the initial Blob to return one with its own 
>> independent lifetime, the same notion will be needed in other APIs which 
>> conceptually clone the data – namely FormData, any place the Structured Clone 
>> Algorithm is used, and BlobBuilder.
>> Similarly to how FileReader must act directly on the Blob’s data, the same notion 
>> will be needed in other APIs which must act on the data - namely XHR.send and 
>> WebSocket. These APIs will need to throw an error if called on a Blob that was 
>> closed and the resources are released.
> So Blob.slice() already presumes a new Blob, but I can certainly make this clearer.  
> And I agree with the changes above, including the addition of something liked 
> ClosedError (though I suppose this is an important enough error + exception to hash 
> out with HTML and DOM4, and once again, the name is TBD).
> In your implementation, what happens exactly to Eric's edge cases, namely:
> xhr.send(blob);
> blob.close(); // method name TBD
In our implementation, this case would fail. We think this is reasonable because the 
need for having a close() method is to allow deterministic release of the resource. 
Having to wait for send to complete before releasing is non-deterministic, and would go 
against the goal of close().

> // AND
> frameRef.src = URL.createObjectURL(blob);
> blob.close() // method name TBD
> In my opinion, the first (using xhr) should succeed.  In the second, frameRef.src works, 
> but subsequent attempts to mint a Blob URI for the same 'blob' resource fail.  Does this 
> hold true for you?
We agree that subsequent attempts to mint a blob URI for a blob that has been closed 
should fail, and is what I tried to clarify in my comments in 'section 6'.
As an aside, the above example shows navigation to a Blob URI - this is not something we 
Currently support or intend to support.

> -- A*
Received on Wednesday, 7 March 2012 01:13:25 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC