Re: [FileAPI] Deterministic release of Blob proposal

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 <ericu@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 <ferasm@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
>
>