Re: [w3ctag/design-reviews] Files and Directory Entries API with webkit prefixes! (#215)

The FileSystem API dealt with two parts: (1) the file/directory/filesystem types, and (2) the ability to create a "sandboxed" file system for origin-specific storage. Chrome re-used the former for drag-and-drop of directories providing an "isolated" file system, and other browsers implemented the subset necessary for this. The doc that this issue references is a codification of that common subset.

You could imagine multiple sources of such filesystems, such as Chrome provides:
* a sandboxed "best effort" filesystem (akin to Indexed DB or the Cache API) - provided in Chrome via `webkitRequestFileSystem(TEMPORARY, ...)`
* a sandboxed filesystem with higher durability guarantees - provided in Chrome via `webkitRequestFileSystem(PERSISTENT, ...)`
* non-sandboxed  "isolated" filesystem provided by certain operations (e.g. directory upload) - provided indirectly by Chrome via `webkitGetAsEntry()`
* non-sandboxed local/native file system access - with some security caveats, e.g. perhaps just for "installed" apps. Chrome has this for installed apps/extensions via `chrome.*` APIs. Not web-facing.
* non-sandboxed "sync" file system that is backed by cloud storage - Chrome has this again for apps/extensions via `chrome.*` APIs. Not web-facing.

It would be reasonable to assume that same file system API (file/directory entries, path resolution, directory traversal, access to file contents, etc) would be used for all of the above cases, as indeed Chrome does. 

Despite recurring interest, no browser has yet tackled web-exposing direct native file/local file system access. Should that happen, we'll need to decide if that should re-use the types here or provide alternate types.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/215#issuecomment-362002334