Re: [File API] Blob URI creation

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?

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.

-- 
Glenn Maynard