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

[Eric U]

On Wed, Nov 16, 2011 at 3:55 PM, Daniel Cheng <dcheng at chromium.org> wrote:
> On Wed, Nov 16, 2011 at 15:31, Glenn Maynard <glenn at zewt.org> wrote:
>
>> On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng <dcheng at chromium.org> wrote:
>>
>>> I'm trying to better understand the use case for DataTransfer.entries.
>>> Using the example you listed in your first post, if I dragged those folders
>>> into a browser, I'd expect to see File objects with the following names in
>>> DataTransfer.files:
>>>     trip/1.jpg
>>>     trip/2.jpg
>>>     trip/3.jpg
>>>     halloween/a.jpg
>>>     halloween/b.jpg
>>>     tokyo/1.jpg
>>>     tokyo/2.jpg
>>> It seems like with that, a web app could implement a progress meter and
>>> handle subdirectories easily while using workers. What does the FileSystem
>>> API provide on top of that?
>>>
>>
>> The issue isn't when you have seven files; it's when you have seven
>> thousand.  File trees can be very large.  In order to implement the above
>> API, you need to traverse the entire tree in advance to discover what files
>> exist.  The DirectoryEntry API lets you traverse the directory explicitly,
>> without having to read the entire tree into memory first, so you don't
>> waste time reading file metadata that you don't care about.
>>
>> For example, you might drag a SVN working copy into a page, which allows
>> viewing logs and other data about the repository.  It might easily contain
>> tens of thousands of files, but you rarely need to enumerate all of them in
>> advance to do useful things with it.
>>
>> (If the trees are on a slow medium, like a DVD drive or a high-latency
>> network drive, even a much smaller number of files can take a long time.)
>>
>> Even when you do want to traverse it all, there are many other advantages:
>> the traversal can be done asynchronously without blocking the page; the
>> page can have a cancel button to abort the operation; the page can show
>> other information about what it's doing (eg. number of new files, number of
>> unrecognized filenames); the page can allow dragging more directories to be
>> queued up for processing without having to wait for the first set to
>> complete; and so on.
>>
>
> I see. I personally feel it's a little confusing to have two different ways
> to read files in DataTransfer, and now we're adding a third.
>
>
>>
>> Also, if a page caches a DirectoryEntry from entries, does that mean it
>>> can continuously poll the DirectoryEntry to see if the contents have
>>> changed to contain something interesting? That seems undesirable.
>>>
>>
>> Nothing needs to be cached.  The DirectoryEntry just represents the
>> directory that was dragged; you don't have to look inside the directory at
>> all until the page uses it.
>>
>
> Let's say I drag my pictures directory to a web app uploader. If this
> uploader passes the DirectoryEntry to my pictures directory to a worker,
> will it be able to read files I create a long time after the original drag?
> It sounds like the approach being advocated would allow that type of attack.

I think it's a bit of an exaggeration to call that an "attack", but
yes, we'll have to make sure we set expectations appropriately.

>>
>>
>> --
>> Glenn Maynard
>>
>>
>>
> Daniel
>