- From: Daniel Cheng <dcheng@chromium.org>
- Date: Wed, 16 Nov 2011 15:55:03 -0800
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