Re: [whatwg] Forms: input type=file and directory tree picking
On Fri, Aug 2, 2013 at 3:39 PM, Glenn Maynard gl...@zewt.org 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. 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
Re: [whatwg] Forms: input type=file and directory tree picking
On Sun, Aug 4, 2013 at 2:47 AM, Jonas Sicking jo...@sicking.cc wrote: 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. Sure we can; we can always add to that API, such as adding a getFileSystem() method. A different @type may be better anyway, though. 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. Unless we think it won't ever happen, it'd be better to keep working towards that than to rush things and implement greedy recursion. 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? It's probably not worth worrying about this part too much until we have a filesystem API for it to enable. Any of these seem fine (though I'd lean away from an API call), or maybe input type=file multiple=fs, which would cause it to fall back on the current (files only, non-recursive FileList) behavior on browsers that don't support it. (I don't think flattening directories into files is something that should ever happen in the first place, but if it does we'd definitely need to make sure it doesn't happen in this mode.) -- Glenn Maynard
Re: [whatwg] Forms: input type=file and directory tree picking
On Sun, Aug 4, 2013 at 4:54 PM, Glenn Maynard gl...@zewt.org wrote: On Sun, Aug 4, 2013 at 2:47 AM, Jonas Sicking jo...@sicking.cc wrote: 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. Sure we can; we can always add to that API, such as adding a getFileSystem() method. A different @type may be better anyway, though. We would also have to expose all files in the selected directory through HTMLInputElement.files, which brings the performance issues that Jonathan is talking about. 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. Unless we think it won't ever happen, it'd be better to keep working towards that than to rush things and implement greedy recursion. Help welcome. / Jonas
