Mirror support

[JulianGro]

Select your issue type: (check at least one)

• Bug
• Question
• Suggestion
• Other (please describe):

Describe your issue:
Hello, is there a good way to provide mirrors? In our case we have two servers that provide the same AppImages, so it feels like a waste to only use one of them for the actual updates.

I am thinking that it would be cool to be able to use them simultaneously, as their bandwidth is obviously limited.
Selecting a mirror bases on ping and hops (like with netselect) might be interesting as well.

For most AppImages this doesn't seem too important, but in our case the AppImage is 1.3GiB so download speed matters quite a bit more.

[probonopd]

Use something like https://mirrorbrain.org/ to redirect to your mirrors. Use the non-redirected URL in AppImage update information. Like the AppImages built on OBS work.

[antony-jr]

@JulianGro Mirrorbrain is highly recommended as @probonopd suggested. Also you could run a torrent seeder in both servers and just use decentralized update using BitTorrent, that will drastically reduce your bandwidth and also gives a lot of speed.

I am thinking that it would be cool to be able to use them simultaneously, as their bandwidth is obviously limited.
Selecting a mirror bases on ping and hops (like with netselect) might be interesting as well.

Mirrorbrain is only thing that comes to my mind. Since we use zsync, we are trying to keep backward compatibility but I'm not sure if we have to. We can add extra options in the zsync meta file to enable mirroring easily without setting up Mirrorbrain. If we do that then no AppImage Update tool will be able to update your AppImage since all other tools will be expecting the legacy zsync meta file.

@probonopd Should we extend the zsync meta file?

[JulianGro]

Wouldn't it be easier to just add multiple URLs into the AppImage update information?
Reason we aren't already using mirrorbrain is that I would like to have redundancy there. If the mirrorbrain server goes down, then the downloads won't work. I mean maybe I am just being picky and I should set up a mirrorbrain server at some point.
Maybe rather than having actual mirror selection it would make sense to provide a backup URL in the AppImage update information?

[antony-jr]

Wouldn't it be easier to just add multiple URLs into the AppImage update information?
Reason we aren't already using mirrorbrain is that I would like to have redundancy there. If the mirrorbrain server goes down, then the downloads won't work. I mean maybe I am just being picky and I should set up a mirrorbrain server at some point.
Maybe rather than having actual mirror selection it would make sense to provide a backup URL in the AppImage update information?

@JulianGro It is possible but we need to follow the AppImageSpec. But you can ask @probonopd to consider changing the spec on this.

I could introduce new methods for you to include mirrors. Then start the update. This will avoid the AppImage Update information and use the one given by the programmer, something like this...

QAppImageUpdate updater;
QVector<QUrl> mirrors;
mirrors.append(QUrl("https://link2..."));
updater.setAppImage(QJsonObject {
   {"type", "zsync"},
   {"primary_link", "https://link1..."},
   {"mirror_links", mirrors}
});
updater.start();

Do you want something like this??

Note: This is under the assumption that you are doing update within your application. (If you do that then the updater can be customized however you like.)

[JulianGro]

I could introduce new methods for you to include mirrors. Then start the update. This will avoid the AppImage Update information and use the one given by the programmer, something like this...

QAppImageUpdate updater;
QVector<QUrl> mirrors;
mirrors.append(QUrl("https://link2..."));
updater.setAppImage(QJsonObject {
   {"type", "zsync"},
   {"primary_link", "https://link1..."},
   {"mirror_links", mirrors}
});
updater.start();

Defining mirrors would definitely make it easier on the developer adding the update functionality while also not relying on a single server.

It would generally be valuable to be able to use update information that is not embedded in the AppImage.
In our case for example it would make sense to be able to switch between branches or even manually supply a URL to update to a test build.
An updater like this isn't just a way to update an AppImage, but also a way to save a lot of traffic when changing to any different version. Our AppImage is 1,3GiB and we actually have users with monthly traffic limits as low as 20GiB.

[antony-jr]

I could introduce new methods for you to include mirrors. Then start the update. This will avoid the AppImage Update information and use the one given by the programmer, something like this...

QAppImageUpdate updater;
QVector<QUrl> mirrors;
mirrors.append(QUrl("https://link2..."));
updater.setAppImage(QJsonObject {
   {"type", "zsync"},
   {"primary_link", "https://link1..."},
   {"mirror_links", mirrors}
});
updater.start();

Defining mirrors would definitely make it easier on the developer adding the update functionality while also not relying on a single server.

It would generally be valuable to be able to use update information that is not embedded in the AppImage.
In our case for example it would make sense to be able to switch between branches or even manually supply a URL to update to a test build.
An updater like this isn't just a way to update an AppImage, but also a way to save a lot of traffic when changing to any different version. Our AppImage is 1,3GiB and we actually have users with monthly traffic limits as low as 20GiB.

@JulianGro I would take that as a yes. I will add this feature ASAP. (In the current version we have a way to give a AppImage but not update information, so now we will be implementing a method to accept custom update information in setAppImage method)