- From: Glenn Maynard <glenn@zewt.org>
- Date: Fri, 2 Aug 2013 17:39:13 -0500
- To: Jonathan Watt <jwatt@jwatt.org>
- Cc: whatwg <whatwg@lists.whatwg.org>
On Fri, Aug 2, 2013 at 11:15 AM, Jonathan Watt <jwatt@jwatt.org> wrote: > In my prototype implementation it took around 30 seconds to build the > FileList for a directory of 200,000 files with a top end SSD; so depending > on what the page is doing, directory picking could take some time. A static list isn't appropriate for recursively exposing a large directory. I hope that won't be implemented, since that's the sort of halfway-feature--"not quite good enough, but it sort of works"--that can delay a good API indefinitely. An interface to allow scripts to navigate the tree like a filesystem should be used, to avoid having to do a full recursion. For example, a photo browser probably only wants to read data on demand, as the user navigates. Also, doing it synchronously means that if the user adds another photo, he'd have to reopen the directory (and wait for the long recursion) all over again for it to be seen by the app. A previous discussion (on drag and drop, but the issues are the same) is here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033814.html That centered around FS-API, which is probably not the direction things are going, but whichever API things land on for filesystem access should probably be used for this--or vice-versa, if this comes first. I suspect they're actually the same thing, since a file picker (along with drag and drop) is the likely way to expose a filesystem-of-real-files API. -- Glenn Maynard
Received on Friday, 2 August 2013 22:39:40 UTC