<CAMWgRNbjGKTrbmMCCMvjr=QkX=DhPok2pQVL=pqGEr_YfOOkUQ@mail.gmail.com>
Current votes: None.
On Fri, Nov 18, 2011 at 1:00 PM, Glenn Maynard <glenn@zewt.org> wrote: > On Thu, Nov 17, 2011 at 10:47 PM, Kinuko Yasuda <kinuko@chromium.org> wro= te: >> >> I mean the URL would essentially be a weak reference to the backing >> file, but it won't keep the backing file alive. >> (At least in sandboxed cases) the filesystem URLs are more like >> 'public address' and not coupled with any particular Entry instances. >> One can make up a URL just by concatenating strings and then can get >> the Entry from the URL. > > Right, but we're talking about the non-sandboxed case. > >> What I'm going to do is: create a set of capabilities upon drag event, >> give the capabilities to the context when it was dropped, and revoke >> the capabilities when the context gets deleted (i.e. the page is >> closed). =A0The lifetime of the Entry instance object doesn't matter in >> this case; Entry is yet another weak reference to the backing file but >> doesn't mean a live reference or access right. > > This implies a memory leak, as each time you drag a file into a page, you > permanently (for the lifetime of the document) create a record that the p= age > is allowed to access that file.=A0 If you drag lots of individual files i= nto > the page, this leak could become nontrivial.=A0 I don't think a design wi= th > inherent memory leaks is a good direction. I would say the approach has a bloating per-page bookkeeping problem but not a 'leak'. Actually chrome does record such per-file/per-directory permission for each page regardless of whether we support DirectoryEntry or not, and so far our observation tells that the amount of memory necessary to keep su= ch permission is negligibly small. If we needed to keep actual data in-memory along with the permission (like we do for Blob) the problem would have been serious but I don't think that'd be a big issue in this case. > -- > Glenn Maynard > >