3 ms·

I do not want better UX to read and write a single file. None of the example apps I mentioned work well with R/W to a single file except maybe the image editor

by jitl 2y ago

I do not want better UX to read and write a single file. None of the example apps I mentioned work well with R/W to a single file except maybe the image editor example. I want permission to create, read, write, move/rename files and directories within a root directory selected by the user. Anything less is not sufficient for AAA quality local-first apps. I think window.showDirectoryPicker() is fine. I hope Firefox will implement this or a similar API, but I am also okay with launching major features without Firefox support. I have done so before to no discernable adverse effects. https://developer.mozilla.org/en-US/docs/Web/API/Window/showDirectoryPicker https://developer.mozilla.org/en-US/docs/Web/API/Window/show...

cxr 2y ago
Nothing I just said is limited to the narrow use case of dealing with single files. If you want improvements for multiple files, then congratulations, you can have that, too! > I want permission to [...] move/rename files [...] Anything less is not sufficient for AAA quality local-first apps. And robbers want to be able to slip their fingers into the wallets of whomever they want. So? Very few apps outside of file managers actually need to be able to move and rename the user's files, and it would be much better if they those that don't would assume they aren't going to be able to. You can call this a prereq for high-quality apps, and I'll maintain my view that apps that refuse to work unless you grant an overbroad set of capabilities that they don't really need are ipso facto low-quality. Besides, if you actually want all this, then you can build an app for remoteStorage.io right now, without needing to know whether the files live on the user's disk or not—and if the user wants the storage area they connect to your app to to be backed by local files, then that's a choice that they can make. Your app doesn't need to be able to discriminate between whether they are or they aren't.
- jitl 2y ago
  Why are you comparing renaming a file inside a directory picked or created by the user to robbers picking a pocket? It's quite typical to implement "atomic writes" by writing to a temporary adjacent file, and once the write is complete, move it to the actual destination filename, possibly overwriting the existing file. For example when exporting a video in a video editor, you might write it first to "$APPDIR/Trip to Spain.webm.incomplete" and then move it to "$APPDIR/Trip to Span.webm" once the file is valid. I am fine if Firefox or any other user-agent mandates that the user can only grant write access to empty directories in order to protect their users from robbers. I'd still be able to build and organize a library of the user's data there, and they'd still be able to edit files with other native apps without needed to upload or download anything. I think the remotestorage.io suggestion a little odd, since the only way it seems one can expose a local filesystem to remotestorage.io apps would be to ask my users to download, install, run, and secure a native, non-web HTTP server program, or to sign up for a third party hosting provider where the files will be off in a cloud. That does not sound like a "local first" app to me :( I find it ironic that a protocol called "remotestorage" touts that it is offline-first design because it keeps user data in inaccessible user-agent storage until the user goes back online, at which point it writes that data to a remote storage provider. Only once the file is written to a 3rd-party server can the user can download the file back to their filesystem. Wouldn't writing a file to the user's filesystem be a more convenient and simple system?
  - cxr 2y ago
    > Why are you comparing renaming a file inside a directory picked or created by the user to robbers picking a pocket? I didn't. Bye.

by jitl 2y ago

cxr 2y ago

Nothing I just said is limited to the narrow use case of dealing with single files. If you want improvements for multiple files, then congratulations, you can have that, too! > I want permission to [...] move/rename files [...] Anything less is not sufficient for AAA quality local-first apps. And robbers want to be able to slip their fingers into the wallets of whomever they want. So? Very few apps outside of file managers actually need to be able to move and rename the user's files, and it would be much better if they those that don't would assume they aren't going to be able to. You can call this a prereq for high-quality apps, and I'll maintain my view that apps that refuse to work unless you grant an overbroad set of capabilities that they don't really need are ipso facto low-quality. Besides, if you actually want all this, then you can build an app for remoteStorage.io right now, without needing to know whether the files live on the user's disk or not—and if the user wants the storage area they connect to your app to to be backed by local files, then that's a choice that they can make. Your app doesn't need to be able to discriminate between whether they are or they aren't.

jitl 2y ago
Why are you comparing renaming a file inside a directory picked or created by the user to robbers picking a pocket? It's quite typical to implement "atomic writes" by writing to a temporary adjacent file, and once the write is complete, move it to the actual destination filename, possibly overwriting the existing file. For example when exporting a video in a video editor, you might write it first to "$APPDIR/Trip to Spain.webm.incomplete" and then move it to "$APPDIR/Trip to Span.webm" once the file is valid. I am fine if Firefox or any other user-agent mandates that the user can only grant write access to empty directories in order to protect their users from robbers. I'd still be able to build and organize a library of the user's data there, and they'd still be able to edit files with other native apps without needed to upload or download anything. I think the remotestorage.io suggestion a little odd, since the only way it seems one can expose a local filesystem to remotestorage.io apps would be to ask my users to download, install, run, and secure a native, non-web HTTP server program, or to sign up for a third party hosting provider where the files will be off in a cloud. That does not sound like a "local first" app to me :( I find it ironic that a protocol called "remotestorage" touts that it is offline-first design because it keeps user data in inaccessible user-agent storage until the user goes back online, at which point it writes that data to a remote storage provider. Only once the file is written to a 3rd-party server can the user can download the file back to their filesystem. Wouldn't writing a file to the user's filesystem be a more convenient and simple system?
- cxr 2y ago
  > Why are you comparing renaming a file inside a directory picked or created by the user to robbers picking a pocket? I didn't. Bye.