Provide issues page in also parseable format (json)

[sidt4]

If I would like to track 10 packages for appstream issues remotely via issues URL, it would require parsing issues page.

Currently, there is just a HTML page for each failing package, as below

https://appstream.debian.org/sid/main/issues/firefox.html

which is not very helpful for parsing.

An additional JSON page per package ( in addition to the current html page ) would be useful.

https://appstream.debian.org/sid/main/issues/firefox.json

[ximion]

See https://appstream.debian.org/hints/

[sidt4]

Great. But, why is there backslash in the package name ?

{
    "hints": {
        "firefox-esr.desktop": [
            {
                "tag": "no-metainfo",
                "vars": {}
            },
            {
                "tag": "icon-not-found",
                "vars": {
                    "icon_fname": "firefox-esr"
                }
            }
        ]
    },
    "package": "firefox-esr\/115.2.0esr-1\/amd64"
},

[sidt4]

See https://appstream.debian.org/hints/

I did visit that link, but didn't download the ".gz" files, as I thought hints are different from actual issues. We should either use one of "hints" or "issues" in all places ( including urls )

[ximion]

Great. But, why is there backslash in the package name ?

Probably some weird escaping rules that the JSON writer employs. Should be gone once you parse it.

[sidt4]

I guess there should be an API for identifying whether "icon-not-found" is an error / warning / info / pedantic etc, and that's how the HTML pages are generated. Is that API public or private to appstream-generator ?

[ximion]

See https://appstream.debian.org/hints/sid/hint-definitions.json

[sidt4]

Is there a reason why we don't have a https://appstream.debian.org/sid/main/issues/firefox.json, when we have a https://appstream.debian.org/sid/main/issues/firefox.html ?

It would be more straight forward than downloading the .gz and processing entire JSON files, just for a handful of apps which can be directly accessed by their JSON urls.

[ximion]

Yes, it's a lot of unnecessary extra work because every system parsing the data prefers parsing all of it instead of jumping to individual pages. So there was no need to implement anything like that.

[sidt4]

I'm not suggesting we should abandon one for the other, but hosting both (all-apps.hints.gz) and https://appstream.debian.org/sid/main/issues/appX.json

[sidt4]

Because, if I'm tracking my 2 apps which I develop, I could just issue HTTP request for those 2 URLs in a for loop (on various distros stable / unstable etc ) and take appropriate action. With all-apps.hints.gz, I've to download the entire file.

Just a thought.

[sidt4]

Also, https://appstream.debian.org/sid/main/issues/appX.json will quickly be accessible when shared in the web, and users (devs) will quickly understand what is possible with that JSON data, and will end up finding and using all-apps.hints.gz.

[ximion]

This was never really intended for app authors, it's more a tool for the respective Linux distributor. However, nothing speaks against app authors using it as well of course, that's probably something that should even be encouraged (could become quite the chore to track the same app across many distros though).

As for even more JSON, I won't work on this as I have already way too much to do and this is a fairly minor feature (it doesn't enable anything that can't already be done), but of course, patches are welcome (but are not that trivial, I'd assume, as the code path for hint generation is very speed optimized and we do little parsing there).