- From: Kinuko Yasuda <kinuko@chromium.org>
- Date: Mon, 21 Nov 2011 19:34:56 +0900
On Sat, Nov 19, 2011 at 7:37 AM, Glenn Maynard <glenn at zewt.org> wrote: > On Fri, Nov 18, 2011 at 1:36 AM, Kinuko Yasuda <kinuko at chromium.org> wrote: >> >> I would say the approach has a bloating per-page bookkeeping problem but >> not a 'leak'. > > It's a reference leak: an object which remains referenced after it's no > longer needed.? I'm not aware of anything standardized in the platform with > this problem.? Also, a lot of toURL use cases would simply not work with > drag-and-dropped files (being able to modify the URL to access neighboring > files; storing the URL for access in a future session). > > Anyway, do you still agree that having Entry structured clonable is a good > idea?? I'm only really worried about toURL if it causes structured cloning > of Entry to not happen, since I think the latter is a much more solid and > useful approach, and more consistent with what we already have. > (Half-solutions make me nervous, because they have a tendency to delay full > solutions.) Yes, I'm feeling that adding structured cloning support for Entry would make sense in non-sandboxed filesystem cases, in order to make the control of lifetime and capabilities more explicit. Probably if we go along the line we shouldn't allow workers to access the entries just by being passed the toURL-generated URLs (unless it is for sandboxed filesystem). Kinuko
Received on Monday, 21 November 2011 02:34:56 UTC