AppImage / AppImageSpec

This repository holds the specification for the AppImage format.
http://appimage.org/
MIT License
71 stars 22 forks source link

Add support for X-AppImage-UpdateUrl, an entry to indicate update urls #41

Closed mijorus closed 4 months ago

mijorus commented 5 months ago

Hi, I'm the developer of Gear Lever, a tool to manage AppImages that recently became quite popular.

I'm opening this issue because I'm about to add a feature to Gear Lever that will allow users to update AppImages given a static URL (something like https://example.com/latest.AppImage)

Gear Lever checks the headers on that resource, both Etag and Content-Length, and notifies if a new release is available.

Now, it would be great if Gear Lever could pull this info automatically from somewhere. I thought that the desktop file would be a good idea, maybe with a custom key called X-AppImage-UpdateUrl, along side the others that you are already using.

What about the current standard to handle update informations? I want to start by saying that most apps I tested don't include any update information, they might be using their own system built into Electron, or no system at all.

The few that do, it's unclear to me, given your documentation here, which should be the user experience. Should the user update the file manually using zsync? Should there be a button somewhere? Should it be automatic? It's not clear, and I guess it is not clear for many app developers.

X-AppImage-UpdateUrl This field in the desktop file could be used by Gear Lever, or any other "appimage manager" app, to indicate an endpoint to ping to check for updates, using an HEAD request and comparing stuff like the file size and the etag (the http etag header).

Opt out As many apps already include their own system, I think it would be a good idea to specify a way to opt out of it. Some thing like X-AppImage-UpdateUrl=Managed could be an idea

Let me know what you think @probonopd

probonopd commented 4 months ago

Hello @mijorus.

The reason that the update information is not stored inside a file inside the AppImage is that we want to make it easy to change the update information without having to extract all AppImages in the case the server URL changes. Therefore, we are using a ELF section in the AppImage to store the update information.

Why would you prefer a field in the desktop file to the currently used ELF section for the update information?

mijorus commented 4 months ago

Hi @probonopd , I thought this desktop entry would have been a good idea for those who don't bother releasing zsync files of their releases.

However, the more I think about it, the more I realize a new desktop entry is probably redundant. I moved on since, trying to do something with the kind of update information we already have.

Btw, as I am basically trying to develop some an update manager, the real important question I would like to ask you is: Which is currently supposed to be the user experience when we need to update an app. Do appimages currently implement some kind of logic that keeps them up to date?

Thank you in advance

probonopd commented 4 months ago

My personal philosophy is:

Currently, there is e.g., AppImageUpdate which users can use to update AppImages. There are many others, check out https://github.com/AppImageCommunity/awesome-appimage.

The imho ideal user experience is if a "check for updates" and "update" functionality is built into the application, similar to https://sparkle-project.org/ does it. E.g., https://github.com/antony-jr/QAppImageUpdate goes in that direction.

mijorus commented 4 months ago

Thank you @probonopd. I'm closing this issue.