file-system-access

Where file handling is concerned, there are at least - File System Access API, https://wicg.github.io/file-system-access/ - File Handling, https://github.com/WICG/file-handling/blob/master/explainer.... - Origin Private File System, https://github.com/WICG/file-system-access/blob/main/AccessH... There was also Storage Foundation API to which the reaction was "I don't think it's an acceptable outcome for the web platform to have that many ways to work with files" :) https://github.com/mozilla/standards-positions/issues/481 This one never saw the light of day.

Huh. Disregard what I wrote entirely, then. Reading through https://github.com/WICG/file-system-access/blob/main/AccessH..., I can see how they’ve bypassed most or all of the problems I saw—I was making unnecessary assumptions. Thank you for correcting me. I am now enthusiastic about OPFS.

I believe FileSystemAccessAPI, as implemented in browsers, does not yet support block level access and locking. Both required to make this work, the developer behind Absurd SQL is working with the team designing the API to ensure it will have support. IndexedDB is the only way of doing this on browsers currently. https://github.com/WICG/file-system-access/issues/323

> Why hasn’t this been tried? https://caniuse.com/sql-storage Supported in Chrome 4, circa January 2010. I'm forgetting the name of it but there is a spec, I think in wicg, for low-level/byte-level file access. This should make using emscripten to compile things like sqlite far more straightforward, to build whatever you want. I like the shout out to streaming changes out of the database, which the author mentions in terms of redux & time travel abilities from having a wal. Server side systems like Debezium for doing this have been gamechanging. At the moment, the high-level file api has no support for watching for changes (https://github.com/WICG/file-system-access/issues/72). Maybe post 1.0 we might see progress. I don't believe the low-level api has anything for watching for changes. From a more meta-assesment level of this article: I

Yes: https://github.com/WICG/native-file-system

Thanks for pointing that out. I missed these 2 items on first glance. Limiting access to certain directories: https://github.com/WICG/writable-files/blob/master/EXPLAINER... Limiting write access to certain file types: https://github.com/WICG/writable-files/blob/master/EXPLAINER... FWIW: On the surface, this appears to contradict the following quote from tfa: > ...ensures that the user is always in full control over what files and directories a website has access to. A sandbox is not full control.

In the main case, where the user is picking a file, the API as proposed in the examples[1] doesn't seem to suggest any ability to pre-select a file in the displayed file picker. Thus, this is a "dialog" where you literally cannot just press "OK"—you have to either select something to open first, or hit "Cancel"! On the other hand, the last example (FileSystemDirectoryHandle.getSystemDirectory) might devolve into the sort of "user presses yes before even reading" permissions system that is so troublesome today. But I feel like the kinds of directories exposed through such a mechanism would likely be fairly innocent (the proposed example being the user's set of installed fonts.) [1] https://github.com/WICG/writable-files/blob/master/EXPLAINER...