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


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