Re: [File API] Blob URI creation

On May 30, 2012, at 6:55 PM, Glenn Maynard <glenn@zewt.org> wrote:

> On Wed, May 30, 2012 at 11:09 AM, Rich Tibbett <richt@opera.com> wrote:
> The first time any resulting Blob URI is dereferenced then user agents would automatically revoke the associated Blob URI, preventing reuse elsewhere. If the web app needed a new Blob URI to use elsewhere they would call Blob.url again to obtain a new, unique, one-time only Blob URI.
> 
> I'm not sure if you've followed the other threads, but the "release on first use" (oneTimeOnly) approach is broken; I hope nobody else is implementing that.  (I don't know why it's in the spec; it's a poor, error-prone interface, and it's inherently not interoperable.)  The "release at the next stable state" (autoRevoke) approach is much more sane.

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