On May 30, 2012, at 6:55 PM, Glenn Maynard <gl...@zewt.org> wrote: > On Wed, May 30, 2012 at 11:09 AM, Rich Tibbett <ri...@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.
