-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement subset of File System Access API #738
Comments
Same could be said for reading folders as well. (but not writing) Clients can update the content in that folder and website can read the newly updated files and folder in that directory with the old entry api (as long as you have not GC it) You can also get all files (recursively) by using So in some since i think that parts of |
It's the writing part that's actually important here. |
Thanks for raising the issue, but after discussion, we've concluded that we need to defer this question. The idea that there might be elements of the specification that are safe to use is not one that we've explored fully. That said, we try to avoid taking specifications à la carte, because that makes it harder to manage interoperability, especially when it results in more complicated feature detection. If we were to consider this idea, we'd like to see a more thorough analysis. That means a crisp definition of what is included, the implications of those choices, and more extensive work on understanding all of the implications (privacy, security, usability, alternatives, feature detection, interaction with other features, use cases and demand). There are potentially good mitigations already in place for some of the risks that have been identified (like a web site modifying a file that is actively in use by another program), but we'd need to see a more comprehensive treatment. Also, it's not clear that this would be responsive to the requests from web developers. I understand that this is asking a fair bit, but it is generally accepted that the proponents of new web features do this sort of work. Opening an issue on this repository isn't the place I'd recommend taking that work, either. The WHATWG processes for new proposals are better suited to handling this sort of thing. |
Implementing some form of a File System Access API is inevitable. There is no other way to efficiently modify large files or sets of files (audio, video, AI models, etc.). |
I agree. |
Request for Mozilla Position on an Emerging Web Specification
Other information
This was previously turned down (#154 and FOSS-Archives@91a1e8c), however, I took notice of the "Mozilla could be supportive of parts" part. I think that this API could provide some specific very important functionality that is not harmful to the user. Please don't close this issue without reading it thoroughly and considering my case.
I think the primary concern with the API is the
window.showDirectoryPicker()
method and the associatedFileSystemDirectoryHandle
. Selecting a directory would allow a website to create and delete any number of files within the directory, and I agree that this is very dangerous, and should not be implemented (or disabled by default).But I believe that
window.showOpenFilePicker()
andwindow.showSaveFilePicker()
and the associatedFileSystemFileHandle
don't create any increased risk to the user than already exists today. This allows only access to one file. Opening and saving files is already possible without this API, but it doesn't provide the same functionality. The only possible problem is a website writing to a file that the user opened, because opening a file traditionally only implies reading, but this can be solved by simply prompting the user. Of course a prompt wouldn't be necessary for files created with showSaveFilePicker, since that already implies writing.Why I think this is important is because FileSystemFileHandle allows streamed downloads for client-generated files. Currently, doing this requires a hack with service workers, which are not accessible in private mode and require a worker script to be hosted (see https://github.com/jimmywarting/StreamSaver.js). Without this you're limited to downloading files that fit within memory. Additionally, it allows seeking within a file and truncating the file.
TL;DR: Implement only
FileSystemFileHandle
and notFileSystemDirectoryHandle
.The text was updated successfully, but these errors were encountered: