Re: Moving File API: Directories and System API to Note track?

On Wed, Sep 19, 2012 at 3:46 PM, James Graham <jgraham@opera.com> wrote:

> Indeed. We are not enthusiastic about implementing an API that has to
> traverse directory trees as this has significant technical challenges, or
> may expose user's path names, as this has security implications. Also AIUI
> this API is not a good fit for all platforms.
>

I don't think there are any unsolvable problems for traversing native
directory trees.  (For example, hard links can be dealt with if they do
turn up--keep track of inodes in parents--and pathname limitations put an
upper limit, preventing infinite recursion.  I think they're very unlikely
in practice--infinite directory loops would break tons of native apps,
too.  No filesystem I've tried in Linux allows it.)  I don't think any
proposals expose user pathnames (eg. above the item that was
dropped/opened).

The main issue that needs to be explored is how to prevent users from
accidentally giving more access than they mean to, eg. pages saying "please
open C:\ and drag in Users", and users not realizing what they're doing.
This is critically important, but I think it's too early to conclude that
this is unsolvable.

(That's a UI issue more than a technical issue.  There are other clearly
technical issues, but I haven't seen any raised that look unsolvable.  The
two tricky ones I've seen are maximum filename/path length limitations, and
valid characters varying between platforms, which have been discussed a lot
and would need to be revisited--it's been too long and I forget where that
left off.)


On Fri, Sep 21, 2012 at 7:37 PM, Maciej Stachowiak <mjs@apple.com> wrote:

> - I'm not keen on exposing portions of the user's filesystem. In
> particular:
>     - This seems like a potential security/social-engineering risk.
>     - This use case seems more relevant to system apps based on Web
> technology than Web apps as such; I fear that system-app-motivated
> complexity is bloating the api.
>

These are the *primary* use cases of a filesystem-like API.  There's lot of
value in being able to let a media player app play and (optionally)
manipulate my local media directories, for example--obviously I won't move
my music into IndexedDB.

(I don't find the sandboxed case very compelling, and while I consider
IndexedDB "to-be-proven" for things like storing gigabytes of data for a
game, it should definitely be given that chance before introducing another
API for that set of use cases.)

    - Many of Apple's key target platforms don't even *have* a user-visible
> filesystem.
>

It's not inconsistent to have APIs that aren't relevant on every single
platform.  When you don't have a user filesystem in the first place, the
use cases themselves go away and you don't care about any of this.

(For the sandboxed case, this isn't relevant.  It would be useful to
separate the sandboxed and native discussions, since except for the API
style question, the issues and objections are almost completely distinct,
and it's sometimes hard to keep track of which one we're talking about.)

- We already have way too many storage APIs. To add another, the use cases
> would have to be overwhelmingly compelling, and highly impractical to serve
> by extending any of the other storage APIs (e.g. IndexedDB).
>

I do find being able to allow users to work with their native data, just as
native apps do, to be overwhelmingly compelling.  I have about 4 TB of
data, and the only way I can use any of it with web apps is by dragging in
individual, flat lists of files, and even that's a strictly one-way street
(FileSaver is only a very tiny help here).

-- 
Glenn Maynard