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

[timeless]

You could cheat by providing a 0 byte file "folder/nul" and define it
to not be created. On Windows (dos), such a file is used to test for
the existence of a directory, and it's illegal to create a file by
that name.

On 11/15/11, Jonas Sicking <jonas at sicking.cc> wrote:
> 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
>

-- 
Sent from my mobile device