This API can allow applications that work with files to be made as strongly-sandboxed web apps instead of unsandboxed applications
That's possible today using the browser's existing file-handling APIs. As the author points out, there is a hurdle—and possible annoyance—from the user's perspective, which is that rather than pressing Cmd+S (or whathaveyou) and having that silently "just work" (i.e. as it does any any traditional desktop app), the user is kept in the loop during the entire process, from placement (i.e. which directory to save the file to), to having to explicitly grant the ability to overwrite the existing file if one already exists with that name.* Despite the fact that it's possible, however, few application authors have taken advantage of the opportunity. I don't expect this to change much with file access APIs.
The truth of the matter is that the majority of contemporary web app authors like having the opportunity of being the gatekeepers for the user's data—even when the other party 99% of the time is the user themselves.
What's most likely to happen is that similar numbers of web app authors continue not to use these APIs as we see today, partly because the API is too complicated. Where we will see it used will be instances where the net effect to the user is further loss of control over their data.
I'd be in favor of a drastically simplified API that was narrowly created to address the ergonomics issues of the file overwrite problem, and to encourage browser makers to limit further file access API expansion to applications that are themselves accessed with the `file` URI scheme. That is, rather than navigating to hosted web app and granting it permissions for file access, in addition to saving your data to your local disk, you're given a static copy of the web app, too. You're able to open this from disk and it is this copy to which you are allowed to grant file access permissions. If it's true that developers really do care about these file access APIs for the purpose of enabling users to exercise greater control over their data, then they should have no issue making this concession as a show of good faith.
* A simple workaround to this is to not try to overwrite the original, but instead save a new file that sits beside the old one. The application author can help out here by automatically generating a "tag" included in the suggested file name, so when the system filepicker is called up, the user just presses Enter and is never bothered with the overwrite prompt. Many people end up creating their own ad hoc versioning schemes ("final final final") at some point, anyway, so this constraint—which is on the surface considered more onerous than the status quo for typical desktop apps—can actually lead to a workaround that is much nicer to work with than the status quo. (Food for thought: if we reached a stable equilibrium concerning the conventions on this, OS vendors could bake awareness in somewhere just above the filesystem level and kill of "final final final" completely—and expose all sorts of useful services that would not otherwise be possible with the ad hoc schemes.)
Comments
That's possible today using the browser's existing file-handling APIs. As the author points out, there is a hurdle—and possible annoyance—from the user's perspective, which is that rather than pressing Cmd+S (or whathaveyou) and having that silently "just work" (i.e. as it does any any traditional desktop app), the user is kept in the loop during the entire process, from placement (i.e. which directory to save the file to), to having to explicitly grant the ability to overwrite the existing file if one already exists with that name.* Despite the fact that it's possible, however, few application authors have taken advantage of the opportunity. I don't expect this to change much with file access APIs.
The truth of the matter is that the majority of contemporary web app authors like having the opportunity of being the gatekeepers for the user's data—even when the other party 99% of the time is the user themselves.
What's most likely to happen is that similar numbers of web app authors continue not to use these APIs as we see today, partly because the API is too complicated. Where we will see it used will be instances where the net effect to the user is further loss of control over their data.
I'd be in favor of a drastically simplified API that was narrowly created to address the ergonomics issues of the file overwrite problem, and to encourage browser makers to limit further file access API expansion to applications that are themselves accessed with the `file` URI scheme. That is, rather than navigating to hosted web app and granting it permissions for file access, in addition to saving your data to your local disk, you're given a static copy of the web app, too. You're able to open this from disk and it is this copy to which you are allowed to grant file access permissions. If it's true that developers really do care about these file access APIs for the purpose of enabling users to exercise greater control over their data, then they should have no issue making this concession as a show of good faith.
* A simple workaround to this is to not try to overwrite the original, but instead save a new file that sits beside the old one. The application author can help out here by automatically generating a "tag" included in the suggested file name, so when the system filepicker is called up, the user just presses Enter and is never bothered with the overwrite prompt. Many people end up creating their own ad hoc versioning schemes ("final final final") at some point, anyway, so this constraint—which is on the surface considered more onerous than the status quo for typical desktop apps—can actually lead to a workaround that is much nicer to work with than the status quo. (Food for thought: if we reached a stable equilibrium concerning the conventions on this, OS vendors could bake awareness in somewhere just above the filesystem level and kill of "final final final" completely—and expose all sorts of useful services that would not otherwise be possible with the ad hoc schemes.)