Re: [Tails-dev] Dynamically changing ISO URL in DAVE

Supprimer ce message

Répondre à ce message
Auteur: sajolida
Date:  
À: tails-dev
Nouveaux-sujets: [Tails-dev] Fallback download URL outside of DAVE [Was: Dynamically changing ISO URL in DAVE]
Sujet: Re: [Tails-dev] Dynamically changing ISO URL in DAVE
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.