-
-
Notifications
You must be signed in to change notification settings - Fork 563
Ecosystem
AppImage itself is a simple format for bundling application binaries. It is basically a self-mounting ISO file that contains an application and everything it needs to run which cannot be expected to be part of the target system(s). See the work-in-progress AppImageSpec.
So now we have a practical solution for upstream projects to provide binaries for Linux, but the user still has to:
- Discover new applications
- Know where to get AppImages from
- Download them
- Make them executable, after having checked whether he trusts them
- Update them
And the application author still has to:
- Understand the details of the AppImage format (hey, it's really simple, but still...)
- Get the application to compile on a "not too recent" distribution such as CentOS 6 for maximum compatibility with "not too recent" target systems
- Integrate the AppImage builds into a continuous build system
- Host the AppImages
- Make the application known to users
- Provide updates
By building an ecosystem around the AppImage format, many of these tasks could be greatly simplified. However, just with AppImage itself, the ecosystem should be designed in a community-driven, de-central, interoperable way with no central gatekeepers or points-of-failure, or (if that is not possible) the least number possible.
The following components, loosely coupled (in the sense that they may be used, but don't have to) could be useful building blocks of the AppImage ecosystem. For comparison, I will mention the equivalent in the Docker ecosystem, which is more tightly coupled (in the sense that it is more centralistic).
While AppImages are intended to be built and hosted by the original authors of applications (upstream), it would still be useful to collect information about AppImages in a central database. This database should ideally be crowdsourced, in the sense that the data should be fetched directly from the upstream application authors; ideally directly from the AppImages published by them on the Internet. The data should be made available for use by by software catalog websites and software centers (syndication). It looks like AppStream can be used for this.
For comparison, Docker Hub is a central registry of available Docker images, but as far as I know, the images must be hosted on Docker Hub in order to be listed in the registry.
Software catalog websites (such as Freecode, Qt Apps, KDE Apps, etc.) list applications in different categories, with "product detail pages" showing descriptions, screenshots, icons, user comments, star ratings, etc. It would be beneficial if such websites could get information and metadata about available AppImages from a central registry of available AppImages if they don't want to collect the information from their users and/or if they don't want to collect the information from AppImages across the Internet.
For comparison, Docker Hub is a catalog website, but as far as I know, there are no APIs for third-party software catalog websites.
Software centers (such as Gnome Software, KDE Discover, etc.) perform similar functions as software catalog websites but are native applications, coming with desktop distributions. In addition, they allow for easy installation/removal/update of applications. Software centers would need to be updated or get a plugin to access the information from the central registry of available AppImages. In addition, they could query AppImages that are already present on the local machine. Software centers could use the information provided to display applications to the user, download them, and update them using zsync-based binary deltas (a sample implementation of which is available in AppImageUpdate).
AppImages need to be built by either taking pre-existing binaries or binary packages and re-packaging them in the AppImage format, or by compiling software specifically for use as an AppImage. While this could be done manually by application authors, the most convenient way is to do this in the cloud as part of a continuous build (CI) system, triggered by changes in the version control system (git mostly these days).
The AppImage build farm would watch a git repository for changes, and if changes occur, start a build on a build slave, and build an AppImage. This would be very similar to what Travis CI can do for GitHub repositories already today, but with the difference that the AppImage build farm would not have to be limited to GitHub repositories, but could also hook into the CI systems of large projects like KDE, Gnome, etc., and would use e.g., a preconfigured default container to build on that would come with the latest compilers, CMake, etc. by default in order to speed up builds. Different containers could be provided, e.g., a CentOS 6 Docker container already containing recent builds of Qt and KF5 for building KDE applications. By utilizing build systems such as Emerge, existing metadata required for building could be utilized and the builds could be automated as much as possible. For comparison, Docker Hub also acts as a build farm - users can provide a Dockerfile, Docker Hub executes the instructions therein to produce a Docker image.
Not everyone will use software centers provided by the distribution. Hence, it would be beneficial to have a library like https://sparkle-project.org/ that application authors could include in their application, which would perform binary delta updates on using zsync-based binary deltas (could be a simple GUI frontend to the existing AppImageUpdate backend).