Re: [File API] Blob URI creation

On May 30, 2012, at 6:48 PM, Glenn Maynard wrote:

> On your main question, I've had the same thought in the past--a "url" property on Blob which simply creates a new auto-revoking blob URL.  I didn't bring it up since I'm not sure if creating a URL for a blob is actually something you do so often that it's worth having a shortcut.  If so, a function is probably better than a property--more future-proof, and it'd be unusual on the platform to have a property that returns a different value every time you read it.
> 
> On Wed, May 30, 2012 at 1:50 PM, Rich Tibbett <richt@opera.com> wrote:
> Yes, this might be a better solution. I was working on what was available in the editor's draft and looking for a way to remove the need to ever call revokeObjectUrl.
> 
> This is part of what's wrong with oneTimeOnly--it *doesn't* actually completely remove the need to call revokeObjectUrl.  For example:
> 
> function f(blob) {
>     var url = URL.createObjectURL(blob, {oneTimeOnly: true});
>     if(showImage)
>         img.src = url;
>     else
>         URL.revokeObjectURL(url);
> }
> 
> Without the revoke case, the URL (and so the whole blob) is leaked as it's never actually used.  autoRevoke doesn't have this problem.
> 
> Arun/Jonas: Can we hide this feature in the spec before more people implement it, or at least tag it with "not ready for implementations" or something?


I'll do one better, and introduce autoRevoke semantics:

http://www.w3.org/TR/2012/WD-FileAPI-20120712/#creating-revoking

By default, this does not need a corresponding revokeObjectURL() call.  In order for Blob URLs to persist past a stable state (for that unit of script) createObjectURL has to be invoked with autoRevoke set to false.


> That is, you shouldn't ever have to pass a Blob URI obtained via Blob.getURL through revokeObjectUrl because it assumes some auto-revocation behavior. Using microtasks to release at the next stable state does seem ok as long as developers have a very good understanding of when a Blob URI will be implicitly revoked. Saying that you can use a Blob URI exactly once, as per onetimeonly could still end up being easier to understand though.
> 
> (s/microtasks/stable states/; they're not quite the same)
> 
> It's actually a bit hard to understand (or easy to misunderstand), since there's no clear concept of "using a URL".  For example, if you start two XHR's on the same URL one after the other in the same script, the order in which the fetches actually begin is undefined (they happen in different task queues), so which would succeed is undefined.  (Some work would also be needed here for the autoRevoke approach, but it's much simpler.)
> 
> autoRevoke is pretty simple from the user's perspective: the URL is revoked when your script returns to the browser.
> 

In fact, I think this addresses the lion's share of use cases, and if a developer wants to explicitly create "longer lasting" Blob URLs, they have that option (just not by default).

-- A*