<CAHvSExf-9CBCvX0F=a0Z+OCDvPUOYEXk=cWfVGATK28Uc=GJBQ@mail.gmail.com>
Current votes: None.
On Wed, Nov 16, 2011 at 3:55 PM, Daniel Cheng <dcheng@chromium.org> wrote: > On Wed, Nov 16, 2011 at 15:31, Glenn Maynard <glenn@zewt.org> wrote: > >> On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng <dcheng@chromium.org> wrot= e: >> >>> 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 fol= ders >>> into a browser, I'd expect to see File objects with the following names= in >>> DataTransfer.files: >>> =A0 =A0 trip/1.jpg >>> =A0 =A0 trip/2.jpg >>> =A0 =A0 trip/3.jpg >>> =A0 =A0 halloween/a.jpg >>> =A0 =A0 halloween/b.jpg >>> =A0 =A0 tokyo/1.jpg >>> =A0 =A0 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 FileSys= tem >>> API provide on top of that? >>> >> >> The issue isn't when you have seven files; it's when you have seven >> thousand. =A0File trees can be very large. =A0In order to implement the = above >> API, you need to traverse the entire tree in advance to discover what fi= les >> exist. =A0The DirectoryEntry API lets you traverse the directory explici= tly, >> 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. =A0It might easily con= tain >> 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 advantage= s: >> 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 wa= ys > 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. =A0The 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 dra= g? > It sounds like the approach being advocated would allow that type of atta= ck. 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 >