> From: Arun Ranganathan [mailto:aranganat...@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 
>> 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 
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 
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*

Reply via email to