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

Hi Glenn,

I read over your points. But I don't think they would change Apple's calculation about exposing an API to the real user filesystem in Safari, particularly as specified. I do think that my more minimal API might also be a better fit for the "real filesystem" use case, as it removes a bunch of unnecessary levels of indirection and abstraction that exist in the other proposals. But I think it is unlikely we would expose that aspect.

We are still open to solving the "sandboxed local storage area" use case, with a more minimal API. But first we'd like to understand why those use cases can't be solved with targeted additions to IndexedDB (see forked thread).

Regards,
Maciej

On Sep 25, 2012, at 12:35 PM, Glenn Maynard <glenn@zewt.org> wrote:

> 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
> 
>