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

[Glenn Maynard]

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.

 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