W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2011

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

From: Kinuko Yasuda <kinuko@chromium.org>
Date: Wed, 16 Nov 2011 12:58:52 +0900
Message-ID: <CAMWgRNaUwRH=5jYwVvY_KBBjoe4BQVaJXC0dXthrZLAYK5jAQg@mail.gmail.com>
On Wed, Nov 16, 2011 at 11:06 AM, Glenn Maynard <glenn at zewt.org> wrote:
> On Tue, Nov 15, 2011 at 8:38 PM, Kinuko Yasuda <kinuko at chromium.org> wrote:
>>
>> The async nature of DirectoryEntry makes the code longer,
>> but webapps can work on the files incrementally and can show
>> progress UI while enumerating. ?For the apps that may deal with
>> potentially huge folders providing such a scalable (but slightly
>> more cumbersome) way sounds reasonable to me.
>
> Entry (and subclasses) should also be supported by structured clone.? That
> would allow passing a DirectoryEntry received from file inputs to be passed
> to a worker.? This is something for later, of course, but combined with an
> API to convert between Entry and EntrySync (and DE/DESync), this would allow
> using the much more convenient sync API in a worker, even if the only way to
> retrieve the Entry in the first place is in the UI thread.

Good point, we could do this synchronously in workers!
I think we already have one way to convert Entry to EntrySync:
we can get a URL from Entry (Entry.toURL()), send the URL to
the worker and get the EntrySync via resolveLocalFileSystemSyncURL.

http://www.w3.org/TR/file-system-api/#widl-Entry-toURL

> I think this is a better solution to the inconvenience of async APIs than
> falling back to exposing unscalable sync interfaces in the main thread.
> This is one of the reasons we have workers.

Agreed.

> --
> Glenn Maynard
>
>
Received on Tuesday, 15 November 2011 19:58:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:09 UTC