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

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

Received on Tuesday, 15 November 2011 15:13:22 UTC