W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [File API] Blob URI creation

From: Rich Tibbett <richt@opera.com>
Date: Wed, 30 May 2012 20:50:31 +0200
Message-Id: <D3AEAE0F-8821-4865-B3C7-0F9DE239D56F@opera.com>
Cc: public-webapps <public-webapps@w3.org>
To: Glenn Maynard <glenn@zewt.org>
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.
Received on Wednesday, 30 May 2012 18:51:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT