Re: File Save As

On Sun, Mar 29, 2015 at 2:38 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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

Will review.


> > - Right click save-as
>
> This is doable using a blob:-URLs and <a href="..."> or <a href="..."
> download>
>
It's not. In order to provide the blob you've got to have the data ready
and in blob form. The data could take a while to be prepared, it could
require streaming in from a worker, it could require reading back from the
GPU, and it could be large. It's not feasible to keep an up to date copy of
data in blob form at all times in case somebody desires to save as just in
case.

You'd want to do three things:

   1. Be able to provide data asynchronously (for either click or right
   click -> save as)
   2. In case of longer running data productions have the option to provide
   a progress (and let the browser handle the d/l progress meter as usual)
   3. Be informed if a download is canncelled so you can stop producing
   needless bytes.

> - 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.
>
I agree that this is a UX issue. However, please don't follow this pattern
of solving it: http://codeflow.org/issues/permissions.jpg