- From: Eric U <ericu@google.com>
- Date: Wed, 16 Nov 2011 15:59:47 -0800
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 >
Received on Wednesday, 16 November 2011 15:59:47 UTC