Re: File API "oneTimeOnly" is too poorly defined

On Wed, Mar 28, 2012 at 5:49 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Mar 28, 2012 at 4:36 PM, Glenn Maynard <glenn@zewt.org> wrote:
> > 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.htmlmay
> > 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.
>
> This is an interesting idea for sure. It doesn't solve any of the
> issues I brought up, so we still need to define when dereferencing
> happens. But it does solve the problem of the URL leaking if it never
> gets dereferenced, which is nice.


I've never been terribly happy with createObjectURL and the requirement for
folks to remember to call revokeObjectURL.  I really like that we're talking
about ways to minimize this pain :-)

I noticed the WeakRefs proposal:
http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs

It also makes use of the micro-task concept, and it does so to avoid
revealing
details about garbage collection.

What if we were to adopt a similar approach here.  Instead of introducing a
second parameter to createObjectURL, what if createObjectURL returned a
WeakObjectURL object instead of a String object?  WeakObjectURL could
be converted to a String to reveal the Blob URL.

Suppose WeakObjectURL if retained would keep the Blob URL valid.  Else,
when WeakObjectURL gets deleted, its Blob URL would remain alive up
until the next micro-task.

Crazy idea?  Too crazy?

I agree that it is valuable to define "dereference" points for APIs that
receive
Blob URLs.

-Darin