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

[Kinuko Yasuda]

Apologies for my late response.

  On Tue, Apr 10, 2012 at 7:33 AM, Glenn Maynard <glenn at zewt.org> wrote:

> On Mon, Apr 9, 2012 at 3:35 AM, Kinuko Yasuda <kinuko at chromium.org> wrote:
>
>> I don't think we should do this.  The change would be invasive and could
>> delay firing a drop event indefinitely if the number of dropped files is
>> very huge.
>>
>
> This feels like the wrong optimization.  It's making this API more
> cumbersome for all users, for an unlikely case: selecting tons of
> individual files that can't be stat()'d quickly.  Usually, files that are
> being dropped have been accessed recently (by the windowing system, when
> the user selected the files), so they're almost always going to be in
> cache.  I think in practice, "delay indefinitely" is an exaggeration.
>

I wasn't fully convinced by the idea of making
dataTransferItem.getAsEntry() synchronous, but per recent "File with
modification" discussion on public-webapps it looks like we're likely
shifting the timing when to grab the file metadata to the timing of File
object creation, and it sounds like it'll match with what you're proposing
here.

That is:
- The UA grab file metadata along with file path when a file is dragged and
dispatches a drag event.
- When DataTransferItem.files, getAsFile or getAsEntry are called, the UA
instantiate a snapshot File object using the captured metadata, or
instantiate a FileEntry or DirectoryEntry based on the type information in
the metadata.

We (Chrome) are not yet ready to grab file metadata at file drag timing but
until then we can probably make a synchronous query just to get the
file/directory type information when getAsEntry() is called (and therefore
it won't affect any other APIs).

 If we keep it asynchronous the Web page could have more control over which
>> to instantiate when, e.g. it could only show the` first few items upon drop
>> and then keep loading more items asynchronously only when necessary.
>>
>
> That's what DirectoryEntry is for.  Adding yet another asynchronous API
> layer on *top* of Entry to allow dropping lots of individual files feels
> like an overcomplication, especially when most of the time, even doing that
> with thousands of files would still be very fast.
>
> It also makes it a lot harder to push file work to workers.  This:
>
> elem.ondrop = function(e) {
>     worker.postMessage({entries: e.dataTransfer.entries})
> }
>
> becomes something like this:
>
> elem.ondrop = function(e) {
>     var items = e.dataTransfer.items;
>     var nextEntry = 0;
>     var entries = [];
>     var gotEntry = function(ent) {
>         if(ent != null)
>             entries.push(ent);
>         if(nextEntry == items.length) {
>             worker.postMessage({entries: entries});
>             return;
>         }
>
>         e.dataTransfer[nextEntry].getAsEntry(gotEntry);
>         ++nextEntry;
>     }
>     gotEntry(null);
> }
>
> The point of using workers here would be to avoid all this (with sync
> APIs)...
>

> On Mon, Apr 9, 2012 at 12:21 PM, Eric U <ericu at google.com> wrote:
>
>> 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.
>>
>
> That's how I've always viewed Entry (and File): its existence in your
> context is what gives you access to the file it represents.  URLs can't do
> that.
>
> --
> Glenn Maynard
>
>