Re: [FileAPI] createObjectURL isReusable proposal

Glenn points out that the issues raised in this thread weren't totally taken to the mat. Once again, sorry for bad nesting in my response: 

> > We can certainly talk through some of these issues, though the
> > amount
> > of
> 
> > work we'd need to do doesn't go down. Our proposal is a small
> > change
> > to
> 
> > the lifetime management of the Blob URL and was relatively simple
> > (for
> 
> > us) to implement. In our experience, createObjectURL is a good
> > broker
> 
> > in web developers minds for switching from object to URL space.
> 

> I'd expect making this fully interoperable to be a complex problem.
> It makes fetch order significant, where it currently isn't.

> For example, if two images have their @src attribute set to a URL one
> after the other, what guarantees which one succeeds (presumably the
> first) and which fails (due to the first releasing the URL)? The
> order in which synchronous sections after "await a stable state" are
> run isn't specified. Combining different APIs which do similar
> things (eg. asynchronous XHR and HTMLMediaElement's resource
> selection algorithm) would compound the problem.

Adding this API increases the likelihood of a race condition; it may not do to simply go all Highlander on this problem ("There can be only one!") and leave it to implementations. Is this an argument to *do away* with the dictionary key for "oneTimeOnly" or to make another spec modification that explicitly calls for a strong reference during HTMLMediaElement's resource selection algorithm (is such an ask even possible)? 

You point out later on [1] that this can also be true of revoke* for async XHR. 

> Another possible problem, depending on where the blob release takes
> place: if the UA doesn't support images, "update the image data" for
> HTMLImageElement terminates at step 4; it would need to be careful
> to still release the blob URL when terminating before the fetch.

This can be another spec detail for UAs that don't support images; in other words, should we have a section on revoke* ("advice to implementors")? 

> This would probably have effects across a lot of specs, and couldn't
> be neatly tucked away in one place (such as inside the resource
> fetch algorithm); and it might force every API that performs fetches
> to worry about creating race conditions with other APIs. Assigning
> the blob directly would still affect various specs, but it would be
> less likely to lead to blob leakage and subtle, possibly racy
> interop failures.

I'm not sure we're at a place where we can contemplate assigning the Blob directly yet. I'm not sure how to spec against racy interop failures, other than list them as caveats. 

Choices seem to be: 

1. Agree that it's a problem, call it out in the spec as best as possible, and move on (add the dictionary). 
2. Agree that it's WAY too big of a problem, and eliminate the dictionary. But we'd have to add more thought to revoke* in the spec. 

-- A* 
[1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1541.html