Re: File API "oneTimeOnly" is too poorly defined

On Thu, Mar 29, 2012 at 2:29 AM, Darin Fisher <darin@chromium.org> wrote:

> 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
>

This exposes GC behavior, though.  They try to reduce that by making it
only collectable during the event loop, but it's still observable.  For
example,

blob = createObjectURL();
blob = null;
setTimeout(function() { img.src = blob; }, 0);
return;

might or might not succeed.

(IIRC, WeakMaps avoid GC exposure by being non-enumerable.  That seems to
make them not very useful, since it's hardly different from simply
assigning properties to the object.)

On Thu, Mar 29, 2012 at 6:08 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> It might be a bit better to revoke the URL at the next stable state.
> Microtask checkpoints can happen during synchronous script execution.
>

I'm confused.  I'd never seen microtasks actually defined (only suggested),
but I see it's just not defined in the page I was viewing.  It looks like
Google's returning out of date spec links (
http://www.whatwg.org/specs/web-apps/current-work/.w3c-html-core/webappapis.html#processing-model-2).
 This is the second time I've been bit recently by landing on a weird,
out-of-date spec URL (ignoring the /TR/ trap, which I know to watch out
for)...

So, "microtask" isn't what we need here (and not what IndexedDB needs,
either).  Stable state might be correct.  I think that has another effect,
which you don't get by waiting for the event loop: blob URLs would also be
freed between <script> execution.  That is, in

<script>url = URL.createObjectURL(blob); ...</script><script>...</script>

the blob is released before the second <script> is run.  That seems like a
plus.

getObjectURL(blob, {auto: true}) would simply do:

N+1. Return the generated url, and then continue running this algorithm
asynchronously.
N+2. Await a stable state.
N+3. Revoke url.

which doesn't require any new concepts.

I'd suggest "auto" as the option name; it's short, since it'd probably be
used a lot.

On Thu, Mar 29, 2012 at 3:03 AM, Charles Pritchard <chuck@jumis.com> wrote:

> Any feedback on what exists in modern implementations? MS seems to have
> the most hard-line stance when talking about this API.
>

As far as I could tell, MS implemented something behind closed doors,
presented it whole, and then more or less refused to change anything,
despite the serious issues pointed out in it.  Web API development can't
work that way in 2012.

-- 
Glenn Maynard