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.bars...@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 > >
