[whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry
kinuko at chromium.org
Thu Apr 5 21:42:02 PDT 2012
On Fri, Apr 6, 2012 at 12:52 PM, Glenn Maynard <glenn at zewt.org> wrote:
> 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.
I wanted to make it synchronous, but determining the file type (file or
directory) usually requires blocking file I/O operation, which could spoil
the async nature of this proposal if we perform the blocking stat operation
on every drag-enter event.
> 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
>> 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.)
Supporting structured cloning sounds like the right direction to me too.
> 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.)
Thanks for showing your support, I hope we can uniformly support Entry both
in <input> and native drag-and-drop.
> 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
More information about the whatwg