- From: Glenn Maynard <glenn@zewt.org>
- Date: Thu, 17 Nov 2011 13:55:10 -0500
On Thu, Nov 17, 2011 at 1:00 PM, Kinuko Yasuda <kinuko at chromium.org> wrote: > If we apply the current URL model to non-sandboxed cases, passing > URLs wouldn't imply anything about the lifetime (of the data or of > access rights) and the access rights would simply expire when the > context where the Entry was created goes away. Do you mean that the URL would essentially be a weak reference to the Entry, so the URL won't keep the Entry alive, but will no longer be usable after the Entry is GC'd? I don't think I like that idea, for a couple reasons. For one thing, the collection issues I mentioned don't actually go away, they just change form slightly. For example, if you send the URL to a worker, instead of having to figure out when to revoke the URL, you have to figure out how long you have to keep the Entry around to make sure it doesn't go away before the worker resolves the URL back into its own Entry. It would also expose GC behavior to scripts. Having said that, I'm kinda convinced that structured cloning might > give a clean solution and open up more possibilities with explicit lifetime > control and capability passing.(I guess, though, if we continue this > discussion maybe we should split > the topic and move onto public-webapps?) > If that's a better list for it, that's fine with me. Aside from the "convenience" question that brought it up initially, it's orthogonal to the DataTransfer proposal. > (resending with re-format) It didn't really help :) -- Glenn Maynard
Received on Thursday, 17 November 2011 10:55:10 UTC