On 30.3.2012 0:19, Glenn Maynard wrote:
On Thu, Mar 29, 2012 at 2:29 AM, Darin Fisher <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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.
Brona
