W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: File API "oneTimeOnly" is too poorly defined

From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
Date: Fri, 30 Mar 2012 04:35:48 +0200
Message-ID: <4F751C04.8080707@bauglir.com>
To: public-webapps@w3.org

On 30.3.2012 0:19, Glenn Maynard wrote:
> On Thu, Mar 29, 2012 at 2:29 AM, Darin Fisher <darin@chromium.org 
> <mailto: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 <mailto: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 
> <mailto: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

Sure, weak referencing is probably not well explored approach, but the 
underlying idea applied to blob is interesting: URL creates no reference 
to Blob (from GC perspective), meaning Blob is subjected to GC 
regardless of BlobUrl existence. This would remove the need for revoking 
URL, programmers would only need to maintain blobs they want to be 
persistent (e.g. in some global array).
This seem to solve nothing, because there is still some 
revoking/releasing variable, but the approach is reverse (explicit 
keeping of reference, instead of explicit releasing), which could 
seriously limit the "I forgot to release this" cases. And what you are 
working with is the actual Blob, not some String thing.

Received on Friday, 30 March 2012 02:36:14 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:39 UTC