Re: [FileAPI] createObjectURL isReusable proposal

On 28.1.2012 7:10, Darin Fisher wrote:
> On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson <ian@hixie.ch 
> <mailto: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.
>

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

Received on Saturday, 28 January 2012 08:02:19 UTC