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

[Eric U]

On Thu, Apr 5, 2012 at 8: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.
>
> 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 you point out, persistent access permissions are a big issue, which
I'll leave for another time.
I just wanted to mention that I think that storing an Entry in a
database is a bit odd, since you're not actually storing the file that
it represents, so the data can effectively change or disappear outside
of a transaction.

It might make more sense to store a URL or other locator for the file,
to make it clear that you're storing a reference, not the data itself.
 I suppose that storing an Entry could be like storing a capability
[permission to access the file], but that's for the other discussion.

> 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