A thought about appstream info integration

Hi all.
I’m working on integrating appimage info with appstream using the appimage’s json.
The info contained in it is pretty useful (it also includes screenshots, wow!!) but it lacks all the info about the releases available for a particular app.
My actual workaround is grab the download url and scrap the appimages from there and add the info to our appstream components catalogue. It’s a time consuming task totally avoidable if only the releases info were included in the json.
One of the big advantages of appimage is that multiple versions of one app can coexist without a problem, If the releases were available all of the software centers or any kind of program that relies on appstream will get benefited, and thus implies that appimage will get benefited too.

Example:

"name": "Cerebral-Debugger",
            "description": "Cerebral Debugger",
            "categories": ["Development"],
        "authors" : [{"name":"cerebral","url":"https://github.com/cerebral"}],
        "license" : null,
        "links": [{"type":"GitHub","url":"cerebral/cerebral-debugger"},{"type":"Download","url":"https://github.com/cerebral/cerebral-debugger/releases"}],
        "screenshots" : ["Cerebral-Debugger/screenshot.png"]
        },

If I want to know what releases are availabe I must to fetch them from https://github.com/cerebral/cerebral-debugger/release.

The releases field could be a dict indicating the latest release and all other releases. In both cases (latest and others) the info could be available as a list, because the arch could be aslo included with the version.

Example:

"name": "Cerebral-Debugger",
            "description": "Cerebral Debugger",
            "categories": ["Development"],
            "authors" : [{"name":"cerebral","url":"https://github.com/cerebral"}],
            "license" : null,
            "links": [{"type":"GitHub","url":"cerebral/cerebral-debugger"},{"type":"Download","url":"https://github.com/cerebral/cerebral-debugger/releases"}],
           **"releases":[{"latest":["2.3.0_x86_64"]},"olders":["2.2.0_x86_64","2.1.0_x86_64"]}],**
            "screenshots" : ["Cerebral-Debugger/screenshot.png"]
        },

AppImageHub does not keep track of versions/releases.

The reason is that AppImageHub would otherwise have to either

  • Constantly check for new versions/releases. Since new versions/releases can come out for any applciation at any moment in time, we would have to do this in very short intervals. Which does not scale and is not feasible. Or,
  • Require each applciation author to “ping” AppImageHub whenever a new version/release is available. We have not implemented this so far and we don’t know how many applciation authors would care to “ping” AppImageHub

Hence, the client that is using AppImageHub data should check for the available versions/releases at the moment when the user opens the product detail page to always have the latest information.

Yes I know, but appstream is really fast and look for info “in the wild” isn’t that fast (sometimes it’s even frustrating).
I’ll try to explain:
An user can wait for an app to be installed a long time, as long as there’s a progress indicator (hehe) but same user can’t wait for an app to take 5 o 6 seconds to open a screen when he’s looking for something.
A cron process that get the info from the release url and updates the json perhaps it’s not a bad idea as there’s no need of “real-time” info (at least not in all use cases). A daily cron task could be enough to get a good compromise between the overload of such task and the speed of publish new releases and the software centers could really benefit from the much more faster appstream queries, and if “real-time” info is really needed then, well, “the wild” is ever available.

A silly example: I add an “install when network available” option to a software-center. Perhaps at that moment I’ve no network and can’t check the releases of an app (and also other info that I must get from internet like size or anything else) but if I’ve that info then the user knows what releases are available and can check the right one for him (ie: he wants firefox52).
It’s like apt-cache policy and apt-cache madison, the second is slower and if there’s no good reasons is not used: policy works faster, it could be outdated but is faster and works offline.

I understand what you’re saying but I think that when more info become available at the json, the faster and easier will be query that info.

You are free to implement something like that, but I won’t. I want AppImages to be available in the same instant when a release happens, not a day later.

That’s not a good point in time for downloading applications, then :wink:

I don’t like the fact that in order to get the latest version of, say, git, I need to download the whole metadata about all packages in Debian… - more megabytes than git and all its dependencies.

Perhaps it’s because I am always using crappy Internet (inside trains) is why I don’t appreciate the idea of downloading stuff that is not necessary for the exact application I want right now…

I’ve this already implemented, hooked to apt-get update. It’s in a “dirty stage” of development. It lacks a pair of features (icon search, screenshot cache…) and the code needs a bit of polish but it’s working.

As you say there’re times, could be a train or could be 30 machines sharing a dsl connection, where our access to internet is slow like we were at the XIX century and ip packets were carried by crows, but at those moments I can lose sometime seeking for apps whitout the need of a connection and install them when I’ve a good connection available (ie: humm I need to connect to an ancient java page…, it’s firefox 52 available?).
If it’s mandatory to have a connection in order to get the releases of an app then things like appstream are not as useful as they could be.

I understand that every technology has its own philosophy (specially when we spoke about open software) and I don’t want to start a flame (at least not when I’ve no more than 3 posts, give me some more time xD ). If “releases” are not a wanted feature it’s ok for me even I’m so stubborn that I will continue thinking that it will be great to have that info (but I’ll shut up and close my mouth :wink: )

Cheers