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: Mon, 5 Mar 2012 23:19:38 +0000
To: Arthur Barstow <art.barstow@nokia.com>, Arun Ranganathan <arun@mozilla.com>, Jonas Sicking <sicking@mozilla.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, Adrian Bateman <adrianba@microsoft.com>
Message-ID: <1BF800349B6CDF4C82313F8D9EF3239D03E04537@TK5EX14MBXC273.redmond.corp.microsoft.com>
The feedback is implementation feedback that we have refined in the past few weeks as we've updated our implementation. 
We're happy with it to be treated as a LC comment, but we'd also give this feedback in CR too since in recent weeks we've found it to be a problem in apps which make extensive use of the APIs.

> -----Original Message-----
> From: Arthur Barstow [mailto:art.barstow@nokia.com]
> Sent: Monday, March 05, 2012 12:52 PM
> To: Feras Moussa; Arun Ranganathan; Jonas Sicking
> Cc: public-webapps@w3.org; Adrian Bateman
> Subject: 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.htm
> > l
> >
Received on Monday, 5 March 2012 23:20:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT