[whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

On Wed, Apr 4, 2012 at 11:36 PM, Kinuko Yasuda <kinuko at chromium.org> wrote:

> A follow up about this proposal:
>
> Based on the feedbacks we got on this list we've implemented the following
> API to do experiments in Chrome:
>  DataTransferItem.getAsEntry(in EntryCallback callback)
>

Does this actually need to be async?  The only information you need to
create the Entry are the filename and the file type (file or directory),
which the browser can load before performing the drop, so no file I/O is
needed here.

which takes a callback that returns FileEntry or DirectoryEntry if it's for
> drop event and the item's kind is 'file'.
> Right now it's prefixed therefore its actual name in Chrome is
> 'webkitGetAsEntry'.
> We use kind=='file' in a broader definition here (i.e. a file path which
> can be either regular file or directory file) and didn't add a specific
> kind for directories.
> (Btw we've also implemented DataTransferItem.getAsFile(), so apps can call
> either getAsFile or webkitGetAsEntry for kind=='file' item)
>

If getAsEntry is synchronous, a separate getAsFile method isn't needed.
You can just say transfer.getAsEntry().file(), and reduce the API surface
area a bit.

As for lifetime and toURL() issue, which was the biggest concern in the
> past discussion, we decided not to support toURL/resolveURL on  Entries for
> drag-and-drop, so that it won't leak reference or expose GC period.  A
> dragged file can be accessed only while the script has the Entry instance
> (as well as we do for File object).
>

I agree with this.  toURL makes some sense within the sandboxed filesystem,
but it just doesn't for non-sandboxed use.

> We eventually aim to support structured cloning of Entries but it's not
there yet.

This is sort of a separate issue, but it would be nice to eventually get
full structured cloning support, with support for File/Entry into
IndexedDB.  That is, let me store an Entry into IndexedDB, so I can later
restore it and regain access to the file.  For example, if a user grants my
music player web app access to his MP3 collection, I can store the
resulting Entry in IndexedDB (or History), and the user can load my web app
later and start playing music, without having to re-open the directory
every time.  This needs further thought around user expectations of how
long access grants last, but hopefully it can be worked out eventually.

(We don't need to go into this here; just mentioning it again while it's on
my mind, so people can be thinking about it.)

As for <input type="file"> support I am thinking about adding "AsEntries"
> attribute (so that we do not need to do the automatic recursive
> files/directories retrieval when the attribute is specified) and "entries"
> field, but haven't done anything yet.  (Open to further suggestions)
>

This sounds right, too.  This would make File access from <input>
obsolete.  (File would still avoid at least one asynchronous call for
non-recursive use cases, though, so people will still use it.)

 I hope we can get valuable user feedbacks (as well as from yours) based on
> the implementation.
>

This sounds good.  Once we've played around with this for a while, we can
start thinking about how to safely expose write access.

-- 
Glenn Maynard

Received on Thursday, 5 April 2012 20:52:49 UTC