3 ms·

> It is very common for an application to interact with local files. For example, a general workflow is opening a file, making some changes, and saving the file

by xg15 5y ago

> It is very common for an application to interact with local files. For example, a general workflow is opening a file, making some changes, and saving the file. For web apps, this might be hard to implement. It is possible to simulate the file operations using IndexedDB API, an HTML input element with the file type, an HTML anchor element with the download attribute, etc, but that would require a good understanding of these standards and careful design for a good user experience. Also, the performance may not be satisfactory for frequent operations and large files. > Based on the implementation of different browsers, one entry in the origin private file system does not necessarily map to an entry in the user’s local filesystem — it can be an object stored in some database. That means a file or directory created via the File System Access API may not be easily retrieved from outside of the browser. Honestly, this makes no sense to me. The motivating example is exactly about being unable to interact with the host file system, but then they present a solution that does something completely different. If this is supposed to be yet another storage API, then so be it, but this won't be able to solve the UX problems that the first quote was talking about. Edit: Aha, the spec clears this up a bit: The standard defines different implementations of the file system API. Two of them are the "local" [1] and the "origin private" [2] file systems. The former is indeed a view of the host file system, with picker and all, while the latter is completely independent of the host. Looks like this feature announcement was exclusively about the latter. (The motivating example still make no sense to me as that is a clear use-case for the "local" filesystem implementation, but that seems to be more an issue with the announcement, not with the feature itself) Edit2: Another important distinction is that the local file system requires user interaction to use (with good reason) : You have to show a file picker before you can use it, and subsequently can only access the files and directories the user selected in the picker. So you cannot use this as a behind-the-scenes storage mechanism. In contrast, the origin-private file system requires no permissions and no user interaction. [1] https://wicg.github.io/file-system-access/#local-filesystem https://wicg.github.io/file-system-access/#local-filesystem [2] https://wicg.github.io/file-system-access/#sandboxed-filesystem https://wicg.github.io/file-system-access/#sandboxed-filesys...

jonnycomputer 5y ago
Thanks for clarifying this for me. I'd gone through some of the specs of the File System API, but not nearly thoroughly enough to pick up on this distinction.
ec109685 5y ago
Why does the implementation detail around origin file systems affect the motivating use case from the announcement? Web apps can now create their own file systems and treat objects as files (and it seems directly point to such files) with this api. That wasn’t easily possible before.
- xg15 5y ago
  The type of files accessed is radically different: The local FS acesses already existing files that users typically manage by hand, whereas the origin-private FS accesses files that the webapp created itself and will typically manage internally. In Unix terms, the former gives you access to parts of /home, the latter to parts of /var or /tmp. I'm also not sure if calling them different "implementations" (as I did in the GP) is really the best way to put it. Both filesystem objects implement the same interface, but you call different APIs to obtain the objects in the first place and would use them in different contexts. My issue was that the motivating example was about rebuilding the "open"/"save as" functionality from desktop apps, which the local FS API was tailor-made for - but the announcement is about the origin-private FS API, which has a completely different purpose.

by xg15 5y ago

jonnycomputer 5y ago

Thanks for clarifying this for me. I'd gone through some of the specs of the File System API, but not nearly thoroughly enough to pick up on this distinction.

ec109685 5y ago

Why does the implementation detail around origin file systems affect the motivating use case from the announcement? Web apps can now create their own file systems and treat objects as files (and it seems directly point to such files) with this api. That wasn’t easily possible before.

xg15 5y ago
The type of files accessed is radically different: The local FS acesses already existing files that users typically manage by hand, whereas the origin-private FS accesses files that the webapp created itself and will typically manage internally. In Unix terms, the former gives you access to parts of /home, the latter to parts of /var or /tmp. I'm also not sure if calling them different "implementations" (as I did in the GP) is really the best way to put it. Both filesystem objects implement the same interface, but you call different APIs to obtain the objects in the first place and would use them in different contexts. My issue was that the motivating example was about rebuilding the "open"/"save as" functionality from desktop apps, which the local FS API was tailor-made for - but the announcement is about the origin-private FS API, which has a completely different purpose.