RE: [FileAPI] createObjectURL isReusable proposal

On Wed, 14 Dec 2011, Adrian Bateman wrote:

> On Wednesday, December 14, 2011 10:46 AM, Glenn Maynard wrote:
>>> 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.
>>
>> 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 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 don't think we need interop for race conditions. Trying to use a one-time URL
> twice is supposed to go wrong and I don't think it necessarily has to go wrong
> in exactly the same way in all browsers. You might have the same problem based
> on when you call revokeObjectURL in applications today.

Historically failure to interop on things that were "supposed to go wrong" 
hasn't resulted in people avoiding those things but instead has resulted 
in them depending on the specific behaviour of one implementation.