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

[Kinuko Yasuda]

Thanks for your comments,

On Wed, Nov 16, 2011 at 8:02 AM, 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,

The spec doesn't specifically say if Entry objects should be readable or
writable, though they expose both read/write methods.  Even in the
normal filesystem Entries could appear as readonly if we have no quota.

>> 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.
>> DirectoryEntry is asynchronous, which makes enumerating the tree more
>> painful.

We do similar for <input type=files webkitdirectory> so apps
can fallback to the existing FileList option.
If the # of files is small this works ok, but if the dropped folder
contains tons of files this could make the browser stuck and
the app cannot control the slow traversal part at all.

The async nature of DirectoryEntry makes the code longer,
but webapps can work on the files incrementally and can show
progress UI while enumerating.  For the apps that may deal with
potentially huge folders providing such a scalable (but slightly
more cumbersome) way sounds reasonable to me.

> 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.

Agree, this is one of the biggest issues we wanted to address.

> 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.

Giving a way to make the dropped directory writable (say, by specifiying
'writable' additional attribute) could be interesting, though the UA will
need to explicitly require user intervention and take care of security
issues.

> --
> Glenn Maynard
>
>