- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 29 Mar 2015 14:38:20 +0200
- To: Florian Bösch <pyalot@gmail.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, Webapps WG <public-webapps@w3.org>
On Sun, Mar 29, 2015 at 1:25 PM, Florian Bösch <pyalot@gmail.com> wrote: > It's been over 2 years since I raised this issue the first time. The > specification has not been http://www.w3.org/TR/file-writer-api/ updated in > a year and it states that: > >> Work on this document has been discontinued and it should not be >> referenced or used as a basis for implementation. > > > The problem of how to: > > - Asynchronously write a large file (FileSaver & co.) The spec at [1] cover this use case. Mozilla is interested in implementing, and I've heard positive signals from other browser vendors. Though no commitment yet. [1] covers the same use-cases at the Google edited API that you are referring to. Which includes asynchronously writing a large file. [1] http://w3c.github.io/filesystem-api/Overview.html > - Right click save-as This is doable using a blob:-URLs and <a href="..."> or <a href="..." download> > - Overwrite (simple save) To my knowledge no serious proposals have been made for solving this problem. The problem isn't an API one, but a UX one. I.e. it's easy to design an API which would solve this use case. The hard part is displaying a UI to the user which makes the user understand that read/write access is granted to the website, rather than read-only access as the current filepicker allows. Once that UI problem is solved, it would be trivial to design an API, or reuse an existing API, to solve this. / Jonas
Received on Sunday, 29 March 2015 12:39:17 UTC