W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Forms: <input type=file> and directory tree picking

From: Jonathan Watt <jwatt@jwatt.org>
Date: Mon, 05 Aug 2013 17:11:33 +0100
Message-ID: <51FFCEB5.8020908@jwatt.org>
To: whatwg@lists.whatwg.org
On 02/08/2013 23:39, Glenn Maynard 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.

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.
>
Received on Monday, 5 August 2013 16:12:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC