Writable File API - status?

The web really needs a proper filesystem to properly compete with native apps. I’d love to make WebTorrent (https://webtorrent.io) use the disk instead of in-memory storage, but there’s no clear cross-browser solution. So, in the meantime, torrent data is stored in memory and lost when the user navigates to another page.

I found this effort (https://github.com/wicg/writable-files), originally discussed on this forum in this thread (Writable file API). I think this looks great and would definitely work for our use case!

One thing that could improve it is an option to do without the part where we ask users to pick the location they want to save the file to. If I just need a temporary place to store file data (not in memory), I should be able to do that without prompting the user. Maybe we can add a {sandbox: true} or {temp: true} option that would store the file to a browser sandbox location without prompting the user.

This is similar to what the deprecated FileSystem API use to do. But seems like we can increase the usefulness of this API by supporting that use case. Just set one option, and the browser will pick the file path of your file.

Also: Another question: what is the status of this spec and/or the chances of it getting implemented? I can help rally support from developers on Twitter if that’s helpful. Let me know if there’s another more useful way to help!

I’d really like the Writable File API for building tools on the web – the FS has been a huge hurdle.

With such an API we’d be at the tipping point when you can actually be able to have professional tools on the web in a way that is practical for users. Files are really at the core of all our tooling, whether is for a designer, developer or copywriter; There is always a pipeline of files.

Ideally I’d personally like a user to pick a whole folder for a project to save to or load from. However even the current single-file Writable File API proposal is a significant step forward.

I think you may have missed the File System API that is under active development?

The Filesystem api uses sandboxed files not accessible to the user.

The Open Web Platform Storage team within Chrome have been iterating on an MVP for writable-files. They’re at the point where most browsers have indicated the idea of the API is somewhat interesting. What they want to achieve next is building something that demonstrates the type of behavior they want to enable so there’s something tangible to share and excite other vendors about. Likely polyfilling a sketch of the API on top of FileSystem. I think the best way to engage is to chat with Dru Knox via the repo (I see you’ve already filed an issue!) and keep an eye on updates posted to blink-dev for movement on experimentation.

Author’s OP says he’s ok with sandboxing.

If not, I don’t quite understand why a developer would need access to all parts of a user’s file system.

Additionally, there is already a github issue about this and another discourse thread, so wondering why a new thread is necessary.

Thanks – sounds good. Will engage on the writable-files repo (https://github.com/WICG/writable-files).

I’d definitely like to see both modes, modes where the user cannot see the page’s filesystem, and modes where the user can directly manipulate files for the page outside the browser context. Both are really interesting potent use cases, and no compromise would serve both. But of the two, linking the page’s filesystem to a real directory would be considerably more interesting & useful.

I have same problem i dont know how to save a big file without to convert in a blob loaded all in memory I can understant why is not possble to write a FileWriter where the browser will ask to user for the filename/path where save data.