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

[Jonas Sicking]

On Wed, Nov 16, 2011 at 7:09 AM, Kinuko Yasuda <kinuko at chromium.org> wrote:
> On Wed, Nov 16, 2011 at 5:42 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard <glenn at zewt.org> wrote:
>>> 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.
>>
>> You need to do that anyway to implement the .files attribute, no?
>
> Yes, but even we provide the attribute today it wouldn't give the best
> user experience or could be broken with some likely scenarios.
>
> If we could think of better option I think we should make it available.

I'm not sure I understand what you mean.

As long as you support the .files property, you need to traverse all
files that are selected before firing the final drop event. Otherwise
you risk having to do synchronous IO if someone does access the .files
property.

Though you could do what another email in this thread suggested and
not traverse subdirectories when populating .files. Is that what
you're planning to do?

I'm still not convinced that providing an API which provides
asynchronous traversal of the files is going to lead to a better user
experience. In all scenarios that I can think of, the page which
received the drop is going to want to traverse the whole directory
tree anyway. For example in order to create a list of files which
contain images as to display previews of them. Or to store them in the
sandboxed FileSystemAPI or IndexedDB. Or to submit the files using XHR
to the server.

So by providing references to just the root of directories we are not
in fact reducing IO, just shifting it from the UA doing it to the
webpage doing it. From a user's point of view that doesn't seem to be
an improvement.

/ Jonas