Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson < ian@hixie.ch > wrote: 

> > (From Glenn Maynard)
> 
> > 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.
> 

> (From Darin Fisher)

> 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.
I agree to the extent that minting Blob URLs for one-shot usage should be a non-default option, which is it is specified in the editor's draft (updated as of Feb 2 2012: http://dev.w3.org/2006/webapi/FileAPI/ ). I've also taken a crack at further examples, since I agree that the spec did have examples that "gloss over revokeObjectURL..." Further illustrative examples are welcome. 

URL.createObjectURL certainly can be misused, like other APIs on the web. That said here are a few ideas that may be well worth pursuing: 

1. Note that the URL API, which we've extended in File API, was *originally* a Google proposal by Adam Barth [1]. We should breathe life into it. 

A fair number of things are blocked within WHATWG/HTML5 on it. And, we expressed some enthusiasm for it landing here [2]. It was supposed to give us a "string-free" way of working with URLs. If we did this API right, we could obviate URL.createObjectURL/URL.revokeObjectURL at *some* point. Could we pursue this within WHATWG or have this here? I'm ok with either option. 

2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful in mitigating some of our fears. Hixie, is this possible? 

3. Could we offer debugger + console guidance when URL.createObjectURL calls are made naively, without affiliated URL.revoke*? 

> 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?
Well, I'm a fan of img.src = blob being made a reality, *and* of the URL API being solidified. I'm not 100% sure how we can scope create* to an Element in the DOM. While open to a suggestion that clarifies your thoughts on this, I'm worried that this seems like a big change. 

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

-- A* 
[1] https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en&pli=1 
[2] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0819.html