- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 16 Nov 2011 00:42:31 -0800
On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard <glenn at zewt.org> wrote: > On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking <jonas at sicking.cc> wrote: >> >> Adding FileEntry/DirectoryEntry seems confusing since those are >> generally writable in the FileSystem API spec, right? Additionally, >> DirectoryEntry is asynchronous, which makes enumerating the tree more >> painful. >> >> The way we were planning on exposing this in Gecko is to simply set >> File.name to the full relative path to the folder dropped. So in the >> example above, if the user dropped the "Photos" folder from the >> example above on a page, we'd make .files return a list of 7 Files, >> with names like "Photos/trip/1.jpg", "Photos/trip/2.jpg", >> "Photos/trip/3.jpg", "Photos/halloween/a.jpg", etc. > > That requires a full directory traversal in advance to find all of the > files, though; the tree could be very large.? For example, a sharded > directory tree containing hundreds of thousands of files with individual > frames of a video isn't unheard of, and there's no need to read it all in > advance.? Directory trees with tens of thousands of photos, audio clips, > emails (Maildir), etc. aren't uncommon, either. > > DirectoryEntry's asynchronous API seems to have the same advantages here as > they do for regular filesystem access.? It would also set the stage for > exposing writable directories down the line (eg. drag an input and output > directory for file processing), after the security issues are figured out. You need to do that anyway to implement the .files attribute, no? / Jonas
Received on Wednesday, 16 November 2011 00:42:31 UTC