On 28.1.2012 7:10, Darin Fisher wrote:
On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson <i...@hixie.ch
<mailto:i...@hixie.ch>> wrote:
On Wed, 14 Dec 2011, Adrian Bateman wrote:
>
> [...] the first dereference of the URL revokes it.
>
> This means that you can do something like:
>
> imgElement.src = URL.createObjectURL(blob,false)
>
> and not worry about having to call URL.revokeObjectURL to
release the
> Blob.
I think it's dangerous to assume that the URL will only be
dereferenced
once. For example, it would mean that the above image would break
if the
user toggled images off and back on in a browser that discarded
image data
when the user toggles images off. It would mean that you couldn't
clone
the element and get the image data in the clone. It would mean
that you
couldn't read the image's .src URL and have anything useful.
I share your concerns. This is enough reason to make me not want to
support the one-shot flag. That said, I'm greatly bothered by how easily
createObjectURL makes it to create web apps that accumulate mass
amounts of unreleased and unused memory. Most examples gloss over
revokeObjectURL entirely.
The idea of just letting these blobs accumulate until the document is
destroyed is really unsatisfying. A growing number of apps have very
long-lived main documents. What if createObjectURL were somehow
scoped to an Element in the DOM (not just the Document itself)?
For AJAX apps that are creating and tearing down DOM snippets
frequently, if the blob URLs needed for a particular view were bound to
elements in that view, then perhaps there would be a more natural
cleansing of the blob URL registry.
I'm not sure what a concrete proposal would look like. Maybe
Element.URL.createObjectURL or just Element.createObjectURL?
-Darin
I think the better solution is to have implementations make
keeping object
URLs defined be very cheap, so that nobody needs to ever release them.
Those concerns would make sense if this was the only solution, but one
can always stick with create/revoke approach, if you know, you do not
(and most likely will not) need URL, just one-time method, if you know
you would need it, or it is highly possible, use create/revoke. If you
use one-time method but will try to reuse such URL, you've made
programming error, this is not language/API fault.
Brona
