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

[Jonas Sicking]

On Tue, Nov 15, 2011 at 1:01 AM, Kinuko Yasuda <kinuko at chromium.org> wrote:
> Hi,
>
> We'd like to propose (and experiment in Webkit/chromium) exposing
> dropped files/folders as {File,Directory}Entry defined in FileSystem
> API [1] for better folders/files drag-and-drop support.
>
> [1] File API: Directories and System http://www.w3.org/TR/file-system-api/
>
> Usage scenario:
>   Many sites have 'upload your files' feature, like for
>   your photo images.  HTML5 allows you to do this via
>   <input type="file" multiple> or drag-and-drop feature,
>   but the current solution does not provide clean solution
>   for cases with folders, files/folder mixed cases, or folders
>  with subfolders cases.
>
>  For context, back then we have proposed (and implemented)
>  'directory' attribute for <input type=file> specifically to upload
>  a directory, but the approach does not provide useful information
>  to webapps about which file comes from which folder, neither
>  does it allow apps to control how and when to enumerate
>  directories (e.g. app cannot show progress meter etc even
>  the enumerating part takes long time).
>  http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html
>
> Proposal:
>   Add a new field 'entries' to <input type=files> element
>  and to DataTransfer object, and populate the field with
>   file or directory 'Entries' defined in FileSystem API [1]
>  upon file selection or drop events.
>
>   Since FileSystem API naturally supports tree-structured
>  folder hierarchy, Entry object exposes handy fields like 'isFile'
>  and 'isDirectory', and allows webapps to recursively walk over
>  the nested entries in subfolders via ReadDirectory() method.
>
>   This approach allows webapps to directly interact
>   with the local folder structure, and also allows
>   them to control the enumerating part so that
>   the apps can show nice progress meter if they want.
>
> Security notes:
>  The Entries exposed by this feature must be
>  read-only and isolated in a special temporary
>  filesystem so that the webapps cannot access any
>  other folders outside the dropped ones.
>
> Example:
>   When I choose or drag-and-drop a set of folders
>   in the photos folder like:
>
>     /Users/kinuko/Photos/trip/1.jpg
>     /Users/kinuko/Photos/trip/2.jpg
>     /Users/kinuko/Photos/trip/3.jpg
>     /Users/kinuko/Photos/halloween/a.jpg
>     /Users/kinuko/Photos/halloween/b.jpg
>     /Users/kinuko/Photos/tokyo/1.jpg
>     /Users/kinuko/Photos/tokyo/2.jpg
>     ...
>
>  Via the new 'entries' field the site can access each
>  subfolder 'trip' or 'halloween' by scripting, and can
>  properly organize and process pictures using the local
>  folder structure.
>
>  We can think of similar interesting usage scenarios
>  like local-cloud sync app or bulk 'importer', e.g. importing
>  local source directory to cloud IDE etc.
>
> What are your thoughts about adding folder support using DirectoryEntry?

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.

This has the advantage of being a smaller and simpler API.

The only functionality that I can think of which we'd loose is the
ability to deal with empty directories since they simply wouldn't show
up in the .files list. But I'm not sure there are use cases for that.
As a data point, mercurial and git has both decided not to support
empty directories.

/ Jonas

/ Jonas