One correction:
> - Better resume experience *only* when downloads are interrupted by a
*network failure* on Firefox and Chrome (not Tor Browser):
There won't be any builtin resume support in case of option A. Once ajax
call is disconnected, there's no way to resume it from the same point. What
we can do is build our own pause/resume support by adding a parameter to
the download request that specifies from which point we want to resume the
download but this would be a lot of work at both client end and server end.
On Fri, Jun 9, 2017 at 10:53 PM, sajolida <sajolida@???> wrote:
> Uzair Farooq:
> >> - Some aspects of the download as done by the current extension would
> >> also be affected by Web Extensions, especially the pausing and resuming?
> >
> > Chrome have support for resume/pause.
> >
> > If we handle download ourself, we can
> > also pause/resume programmatically. One thing to note though, Chrome
> > does not allow resume after browser is closed.
>
> Meta: I'm putting Uzair Farooq in explicit copy now. He's the freelancer
> interested in porting DAVE to WebExtensions. Welcome Uzair!
>
> Regarding resuming, let's differentiate three scenarios:
>
> - *Pause* -- the user intentionally pauses the download:
>
> - Chrome: works and easy to find
> - Firefox: works but harder to find (right-click)
> - Tor Browser: works but harder to find (right-click)
>
> - *Interruption* -- the download is interrupted by a network failure:
>
> - Chrome: doesn't work
> - Firefox: doesn't work without DAVE, should work with DAVE
> - Tor Browser: doesn't work even with DAVE because of:
> https://labs.riseup.net/code/issues/10686
>
> - *Restart* -- the browser is restarted
>
> - Chrome: doesn't work
> - Firefox: doesn't work without DAVE, works with DAVE
> - Tor Browser: doesn't work even with DAVE because Tor Browser is
> amnesic.
>
> >> - It would be less coding work to decide to remove the download part
> > from the extension instead of porting it to Web Extensions and Chrome?
> >
> > Yeah, without the download it'd be less work.
>
> Ok, that's important as well.
>
> So, merging here the other technical details that anonym and Uzair
> exchanged off-list we have to choose between the following two options.
>
> Uzair, please correct me if I get some technicalities wrong!
>
> Option A. Keep the download inside DAVE relying on the File and
> Directory Entries API [1] which gives access to a virtual, sandboxed
> file system:
>
> 1. DAVE downloads the ISO into the sandboxed file system.
> 2. It verifies the ISO.
> 3. After the verification succeeds, it asks the user where to save
> the ISO in the real file system.
>
> [1]:
> https://developer.mozilla.org/en-US/docs/Web/API/File_and_
> Directory_Entries_API
>
> - Pros:
>
> - Less UX work and redesign of the web interface. Still, users would
> be asked where to save their download *after* the download finishes
> so some details might change. I haven't thought of this much...
> - Better resume experience *only* when downloads are interrupted by a
> *network failure* on Firefox and Chrome (not Tor Browser):
> - The resume experience is not better than option B when the
> *browser is restarted* because with this API we're in a virtual
> file system only in memory so I understand that it's lost when
> the browser restarts.
> - When people want to *pause and resume manually* we're not
> offering more possibility that the vanilla download. Still, we
> might be able to provide a slightly better UX for Firefox where
> this feature is harder to find.
>
> - Cons:
>
> - We're downloading in memory so users need ~1GB of RAM to download.
> - We're downloading in memory and don't really know how browsers
> behave with ~1GB in memory.
> - The UX of downloading might be weird if everything happens in a
> sandbox while users expect stuff to happen on their real file
> system.
>
> Option B: We move the download outside of DAVE and rely on the vanilla
> download mechanism of the browser.
>
> - Pros:
>
> - Less code at the end in DAVE.
> - Less coding work overall when doing the port.
> - Probably less code at the end in the web interface.
> - We're sure that would work fine.
>
> - Cons:
>
> - More UX work and more coding work on the web interface:
> - Redesign the steps of DAVE, removing the download.
> - Redesign the workflow of the installation scenarios to force
> people to verify. See [2].
> - Worse resume experience when downloads are interrupted by a network
> failure on Firefox and Chrome (not Tor Browser).
>
> [2]: https://mailman.boum.org/pipermail/tails-ux/2017-May/003385.html
>
> We basically, we have:
>
> - A cool idea (option A) that might or might not work well, would be
> more work for Uzair and less work for me and would be nicer in case
> of network interruptions.
> - A safe bet (option B) that will work, will be more work for me and
> less for Uzair and that will degrade a bit the UX on network
> interruptions.
>
> I would say we should do option B. But I would like:
>
> - More UX comments on option B.
> - More technical review of the implications of option A.
> - anonym and Uzair to check carefully what I'm saying here :)
>
