- From: Eric U <ericu@google.com>
- Date: Wed, 16 Nov 2011 09:01:04 -0800
On Tue, Nov 15, 2011 at 6:06 PM, 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. As Kinuko mentions, toURL obviates the need for structured clone for Entry. I'd rather not add support for that if we can avoid it, and this seems like an acceptable workaround. While the URL format for non-sandboxed files has yet to be worked out, I think we need toURL to work no matter where the file comes from. It's already the case that an Entry can expire if the underlying file is deleted or moved; I think it's OK for the URL to expire under similar circumstances. In the case of a drag, we can just say that it expires when either the page goes away or the underlying file does [analogous to the expiry of the data in a normal drag event, I think, which should last as long as the page does]. > 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. > > -- > Glenn Maynard >
Received on Wednesday, 16 November 2011 09:01:04 UTC