- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 28 Apr 2015 17:05:22 -0700
- To: Travis Leithead <travis.leithead@microsoft.com>
- Cc: Ali Alabbas <alia@microsoft.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Tue, Apr 28, 2015 at 4:26 PM, Travis Leithead <travis.leithead@microsoft.com> wrote: >>> Second, rather than adding a .directory attribute, I think that we should simply add any selected directories to the .files list. My experience is that having a direct mapping between what the user does, and what we expose to the webpage, generally results in less developer confusion and/or annoyance. > > I like this consolidation, but Ali concern (and one I share) is that legacy code using .files will not expect to encounter new Directory objects in the list and will likely break unless the Directory object maintains a backwards-compatible File-like appearance. Legacy pages won't be setting the "directory" attribute. In fact, this is the whole purpose of the "directory" attribute. To enable pages to signal "I can handle the user picking directories". > I have a concern about revealing the user's directory names to the server, and suggested anonymizing the names, but it seems that having directory path names flow through to the server intact is an important scenario for file-syncing, which anonymizing might break. I agree that this is a concern, though one separate from what API we use. I do think it's fine to expose the directory name of the directory that the user pick. It doesn't seem very different from the fact that we expose the filename of the files that the user pick. / Jonas
Received on Wednesday, 29 April 2015 00:06:20 UTC