Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson <ian@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.
>