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
