- From: Glenn Maynard <glenn@zewt.org>
- Date: Wed, 30 May 2012 17:48:29 -0500
- To: Rich Tibbett <richt@opera.com>
- Cc: public-webapps <public-webapps@w3.org>, Arun Ranganathan <arun@mozilla.com>, Jonas Sicking <jonas@sicking.cc>
- Message-ID: <CABirCh_f+8DLzspkjbC4bgv-rkNaHDX5nT6UuaLKsH2nWsmNOA@mail.gmail.com>
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
Received on Wednesday, 30 May 2012 22:48:59 UTC