Re: File API "oneTimeOnly" is too poorly defined

Here's another proposal, which is an iteration of the previous.  It's based
on the "microtask" concept, which is creeping up here and there but hasn't
yet been properly defined.  The idea is that microtasks can be queued (call
it "queue a microtask"), and the microtask queue is executed by the event
loop as soon as the current task completes, so it executes as soon as the
outermost task returns to the event loop.

oneTimeOnly (a poor name in this proposal) would simply queue a microtask
to revoke the URL.

This is simpler, and answers a lot of questions.  It means you can use the
URL as many times as you want synchronously, since it's not released until
the script returns.  Any cases where the ordering may not be strictly
defined (eg. the <video><video> case in
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1265.html may
be like this; I don't know how innerHTML works, exactly) are now defined:
both <video> elements would get the object.

It has another nice side-effect: it's much less prone to leaks.  For
example, under previous approaches, the following code would leak the blob:

function updateProgressMeter() { throw "obscure error"; }
url = URL.createObjectURL(blob, {oneTimeOnly: true});
updateProgressMeter();
img.src = url; // never happens

Since the URL is never actually used, the blob reference leaks.  You'd have
to work around this with careful exception handling, which is precisely the
sort of thing oneTimeOnly is supposed to avoid.  With this proposal, the
URL would always be revoked when the script returns to the event loop,
whether or not it was actually used.

This would still require work in each URL-consuming spec, to define taking
a reference to the underlying blob's data when it receives an object URL.
 I think this is inherent to the feature.

"oneTimeOnly" would be the wrong name with this approach; it should be
something like "autoRelease".

This has one drawback: it doesn't work nicely in long-running Workers,
which may never return to the event loop at all.  I think that's probably
an acceptable tradeoff.

--
Glenn Maynard