Design how the IA+DAVE will support the new mirror pool system
- Rewriting download URL to point to a random mirror.
- We’ll be modifying the download page with JS. If the ISO verification extension plans to do the same, we need to check if these modifications are compatible.
Blocks Tails -
#5 Updated by intrigeri 2015-09-28 04:22:35
- Subject changed from Find out where the installation assistant will retrieve the download URL from to Design how the ISO verification extension will support the new mirror pool system
- Status changed from Confirmed to In Progress
- Assignee set to intrigeri
- % Done changed from 0 to 10
- Blueprint set to https://tails.boum.org/blueprint/HTTP_mirror_pool/
- Affected tool changed from Installation Assistant to ISO Verification Extension
> related to https://labs.riseup.net/code/issues/7161 we were wondering where the installation assistant will retrieve the download URL from?
I had a look and it seems that it’s rather about the ISO verification extension: the assistant itself shouldn’t be affected. Retitling accordingly.
> Eventually, it could use the same JSON file?
The JSON file we have in mind for storing the mirror pool database lacks most data that the ISO verification extension needs, so that would be too simplistic to work. But indeed, the extension will eventually have to rewrite the hostname (
dl.amnesia.boum.org) in URLs the same way as what we plan to do for normal web browsing.
#11 Updated by intrigeri 2015-11-01 04:30:24
- Priority changed from Elevated to High
- Target version changed from Tails_1.7 to Tails_1.8
> I’d like to discuss with Giorgio about that ASAP. Waiting for code to be pushed on
Actually code was pushed for
Feature #8639 so I can now do that. Time has flown though, bumping priority.
#13 Updated by intrigeri 2016-02-11 13:51:35
- Subject changed from Design how the ISO verification extension will support the new mirror pool system to Design how the IA+DAVE will support the new mirror pool system
- % Done changed from 10 to 20
Told the IA+DAVE crew about our plans, asked them the questions I had in mind: https://mailman.boum.org/pipermail/tails-dev/2016-February/010262.html
#19 Updated by Anonymous 2016-03-18 23:48:19
> Giorgio’s reply makes me confident that our proposed design will work. There’s only one remaining question in the thread, plus sajolida’s feedback would be useful.
By “remaining question in the thread” do you mean this:
“The only caveat for integrating it into DAVE is that every time the
extension starts/resume a download or is installed/upgraded/reloaded,
downloader.js loops through all the download jobs already ”known" to the
browser’s built-in download manager and, if any of them matches the URL
in the IDF, picks the active one, or if none is currently active, the
most advanced one and makes it “current”, resuming it if required." ?
#21 Updated by intrigeri 2016-03-25 21:09:45
- Status changed from In Progress to Resolved
- Assignee deleted (
- % Done changed from 80 to 100
- QA Check changed from Info Needed to Pass
> intrigeri wrote:
> > Giorgio’s reply makes me confident that our proposed design will work. There’s only one remaining question in the thread, plus sajolida’s feedback would be useful.
> By “remaining question in the thread” do you mean this: […]
No, this was rather a conclusion, and I’ve already pointed to it on
I think I was rather refering to:
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)?
To which Giorgio replied in https://mailman.boum.org/pipermail/tails-dev/2016-February/010281.html. I think this is well tracked in
Feature #11109 already, so as long as we re-read this thread when we implement that other ticket, we should be good.
So it appears that we have a sensible plan, and I’m closing this ticket.