- From: Kinuko Yasuda <kinuko@chromium.org>
- Date: Wed, 16 Nov 2011 12:58:52 +0900
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