<CAMWgRNaUwRH=5jYwVvY_KBBjoe4BQVaJXC0dXthrZLAYK5jAQg@mail.gmail.com>
Current votes: None.
On Wed, Nov 16, 2011 at 11:06 AM, Glenn Maynard <glenn@zewt.org> wrote: > On Tue, Nov 15, 2011 at 8:38 PM, Kinuko Yasuda <kinuko@chromium.org> wrot= e: >> >> The async nature of DirectoryEntry makes the code longer, >> but webapps can work on the files incrementally and can show >> progress UI while enumerating. =A0For 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.=A0 T= hat > would allow passing a DirectoryEntry received from file inputs to be pass= ed > to a worker.=A0 This is something for later, of course, but combined with= an > API to convert between Entry and EntrySync (and DE/DESync), this would al= low > 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 > >