W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2011

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

From: Daniel Cheng <dcheng@chromium.org>
Date: Wed, 16 Nov 2011 15:55:03 -0800
Message-ID: <CAF3XrKpsXo0eNMNfj_6kc+h94ioNaWTUFg4PpNhncCNLN1JuBg@mail.gmail.com>
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.


>
>
> --
> Glenn Maynard
>
>
>
Daniel
Received on Wednesday, 16 November 2011 15:55:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:09 UTC