It seems like this may be setting up a pattern for other dom objects which are large (like video/audio).
When applied in this context, is "close" still a good verb for them? video.close(); dave PS I'm trying to not bikeshed too badly by avoiding a new name suggestion and allowing for the fact that close may be an ok name. On Tue, Mar 6, 2012 at 12:29 PM, Eric U <er...@google.com> wrote: > After a brief internal discussion, we like the idea over in Chrome-land. > Let's make sure that we carefully spec out the edge cases, though. > See below for some. > > On Fri, Mar 2, 2012 at 4:54 PM, Feras Moussa <fer...@microsoft.com> 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. > > What about: > > XHR.send(blob); > blob.close(); > > 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? > > > 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 > >
