On 02/08/2013 23:39, Glenn Maynard wrote:
On Fri, Aug 2, 2013 at 11:15 AM, Jonathan Watt <jw...@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.
I see this more as a means of getting directory picking working in the existing
content out there that's using file pickers without requiring that content to be
updated (which is not going to happen in the vast majority of cases). I would
hope that it would not _prevent_ a filesystem-like API from being implemented,
although I agree it would inevitably reduce the pressure for such an API. That
said, such an API that everyone agrees on doesn't seem to be materializing any
time soon.
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
Thanks for the link. I've read through that thread.
-Jonathan
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.
