- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 4 Aug 2013 00:47:34 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: whatwg <whatwg@lists.whatwg.org>, Jonathan Watt <jwatt@jwatt.org>
On Fri, Aug 2, 2013 at 3:39 PM, Glenn Maynard <glenn@zewt.org> wrote: > 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. We can't do what you are suggesting for a plain <input type=file multiple> since there's already a defined API for that, and that API only exposes a .files property in the DOM. But we could certainly add some way to enable creating an <input> which exposes files and directories in the DOM, rather than just files. Doing that will depend on coming up with a filesystem proposal which all parties actually agree on implementing, so far we don't have such a proposal. It also requires an actual proposal for what such an <input> would look like. I.e. would it be an <input type=file directory>? Or <input type=file multiple> with some sort of API call saying that flattening directories into files aren't needed? Or <input type=filesanddirectories>? / Jonas
Received on Sunday, 4 August 2013 07:48:28 UTC