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

[Jonas Sicking]

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