- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 21 Dec 2010 16:17:39 -0800
- To: Glenn Maynard <glenn@zewt.org>
- Cc: public-webapps@w3.org
On Tue, Dec 21, 2010 at 4:12 PM, Glenn Maynard <glenn@zewt.org> wrote: > On Tue, Dec 21, 2010 at 2:31 PM, Arun Ranganathan <arun@mozilla.com> wrote: >> I've bolstered the lifetime conformance language with this: >> http://dev.w3.org/2006/webapi/FileAPI/#lifeTime >> >> The only nagging doubt I have about this proposal is that the creation and >> revocation methods (static) are on window.URL, but the actual Blob object >> has an affiliated document, which upon cleanup flushes the URLs affiliated >> with it. > > Related to object URL expiration, is there a mechanism to clone an > object URL? In particular, I'm thinking of what happens if you pass > an object URL to a Web Worker thread or another window in the same > origin: it may want to be able to use that URL without it expiring due > to the original window going away. > > I suppose this would simply mean dereferencing the object URL back to > a Blob (or File, or whatever its original Blob subclass was) in the > new context, and then if needed creating a new object URL from > it--though there doesn't seem to be a way to get a Blob back from an > object URL yet. The solution is to instead pass the Blob object to the worker and inside the worker call URL.createObjectURL(blob). That way you get a URL whose lifetime is tied to that of the worker. But yes, if you've lost track of the Blob and just have the URL that isn't possible, so don't loose track of your blobs :-) / Jonas
Received on Wednesday, 22 December 2010 00:18:33 UTC