Re: [FileAPI] Deterministic release of Blob proposal

Feras - this seems kinda' late, especially since the two-week pre-LC 
comment period for File API ended Feb 24.

Is this a feature that can be postponed to v.next?

On 3/2/12 7:54 PM, ext Feras Moussa wrote:
>
> 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.
>
> 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.
>
> We’ve recently implemented this in experimental builds and have seen 
> measurable
>
> performance improvements.
>
> The feedback we heard from our discussions with others at TPAC 
> regarding our
>
> proposal to add a close() method to the Blob interface was that 
> objects in the web
>
> platform potentially backed by expensive resources should have a 
> deterministic
>
> way to be released.
>
> Thanks,
>
> Feras
>
> [1] 
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1499.html
>

Received on Monday, 5 March 2012 20:52:11 UTC