<CA+c2ei83mmCtyZNtG1fHOxDv03Wme+041f9gZgZiz_8Vy6owHw@mail.gmail.com>
Current votes: None.
On Tue, Nov 15, 2011 at 1:01 AM, Kinuko Yasuda <kinuko@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:
> =A0 Many sites have 'upload your files' feature, like for
> =A0 your photo images. =A0HTML5 allows you to do this via
> =A0 <input type=3D"file" multiple> or drag-and-drop feature,
> =A0 but the current solution does not provide clean solution
> =A0 for cases with folders, files/folder mixed cases, or folders
> =A0with subfolders cases.
>
> =A0For context, back then we have proposed (and implemented)
> =A0'directory' attribute for <input type=3Dfile> specifically to upload
> =A0a directory, but the approach does not provide useful information
> =A0to webapps about which file comes from which folder, neither
> =A0does it allow apps to control how and when to enumerate
> =A0directories (e.g. app cannot show progress meter etc even
> =A0the enumerating part takes long time).
> =A0http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.=
html
>
> Proposal:
> =A0 Add a new field 'entries' to <input type=3Dfiles> element
> =A0and to DataTransfer object, and populate the field with
> =A0 file or directory 'Entries' defined in FileSystem API [1]
> =A0upon file selection or drop events.
>
> =A0 Since FileSystem API naturally supports tree-structured
> =A0folder hierarchy, Entry object exposes handy fields like 'isFile'
> =A0and 'isDirectory', and allows webapps to recursively walk over
> =A0the nested entries in subfolders via ReadDirectory() method.
>
> =A0 This approach allows webapps to directly interact
> =A0 with the local folder structure, and also allows
> =A0 them to control the enumerating part so that
> =A0 the apps can show nice progress meter if they want.
>
> Security notes:
> =A0The Entries exposed by this feature must be
> =A0read-only and isolated in a special temporary
> =A0filesystem so that the webapps cannot access any
> =A0other folders outside the dropped ones.
>
> Example:
> =A0 When I choose or drag-and-drop a set of folders
> =A0 in the photos folder like:
>
> =A0 =A0 /Users/kinuko/Photos/trip/1.jpg
> =A0 =A0 /Users/kinuko/Photos/trip/2.jpg
> =A0 =A0 /Users/kinuko/Photos/trip/3.jpg
> =A0 =A0 /Users/kinuko/Photos/halloween/a.jpg
> =A0 =A0 /Users/kinuko/Photos/halloween/b.jpg
> =A0 =A0 /Users/kinuko/Photos/tokyo/1.jpg
> =A0 =A0 /Users/kinuko/Photos/tokyo/2.jpg
> =A0 =A0 ...
>
> =A0Via the new 'entries' field the site can access each
> =A0subfolder 'trip' or 'halloween' by scripting, and can
> =A0properly organize and process pictures using the local
> =A0folder structure.
>
> =A0We can think of similar interesting usage scenarios
> =A0like local-cloud sync app or bulk 'importer', e.g. importing
> =A0local 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