[whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry
kinuko at chromium.org
Thu Nov 17 19:47:26 PST 2011
On Fri, Nov 18, 2011 at 3:55 AM, Glenn Maynard <glenn at zewt.org> wrote:
> 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 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.
> 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.
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). The 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.
>> Having said that, I'm kinda convinced that structured cloning might
>> give a clean solution and open up more possibilities with explicit
>> 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 :)
Great to know that you could still read my garbled mail :)
> Glenn Maynard
More information about the whatwg