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