W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2011

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

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 15 Nov 2011 18:02:28 -0500
Message-ID: <CABirCh-zzDhWKQdZH9vDHcT7xFTp7eqbYqduA3fd5k7G+ToXLQ@mail.gmail.com>
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.

-- 
Glenn Maynard
Received on Tuesday, 15 November 2011 15:02:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:09 UTC