intrigeri:
>> Beside that, I think the JSON should be fetched every time the UI page
>> is reloaded (of course obeying to server-side caching directives), just
>> like we currently do with the IDF.
>
> I'm afraid I don't know under which circumstances the UI page is
> reloaded, so I lack the background info to integrate this proposal
> into my mental representation of the problem.
>
> @sajolida + @Giorgio: is this done as part of the Installation
> Assistant or DAVE course of operation, or only due to external factors
> (e.g. the user manually reloading the page, or restarting their
> browser)?
I *think* that Giorgio is only referring to a possible manual refresh
from the user. Keep in mind that DAVE is supposed to follow up on
download in the background and a user coming back to the download page
after possibly closing the tab, or to survive a manual page refresh or
browser restart.
The only other issue I see that relates to my work on the assistant, is
the fallback solution outside of DAVE so maybe that's off-topic here.
>From the blueprint I wonder whether it's really worth writing a version
of the JavaScript that works outside of DAVE. You're considering several
cases outside of DAVE and BitTorrent:
A. Release candidates. We're discussing in another thread the
possibility of only relying on archive.torproject.org
for these. I think we need HTTPS there so your JavaScript
outside of DAVE might not be enough to replace this here.
B. People with no JavaScript, wget, etc. It seems like we need the
minimal DNS pool if we want to support these anyway.
C. Direct download link, as proposed on #11024. These people
should anyway be able to do OpenPGP verification on their own so it
won't be advertised very prominently and maybe the minimal DNS pool
you are proposing for (B) could be reused here. Also, having a
constant URL might be nice for these people to bookmark it for
example.
