While working with Discover and Plasma Welcome, I realized that the search by common-id on the search store endpoint is case sensitive. So for instance:
curl -s "https://api.snapcraft.io/api/v1/snaps/search?common_id=org.videolan.VLC"
and
curl -s "https://api.snapcraft.io/api/v1/snaps/search?common_id=org.videolan.vlc"
don’t give the same results.
This is unexpected because AFAICT other appstream related tooling treats this as case insensitive. For instance appstreamcli get org.videolan.vlc and appstreamcli get org.videolan.VLC give the same results.
Any chance to treat common_id as case insensitive on the search endpoint?
Additionally, even though uppercase letters are permitted in a component-ID, it is strongly encouraged to only use lowercase letters for the ID.
Going by the appstream reference implementation, it is indeed case folding before doing a search:
Annoyingly, they’re doing locale dependent case folding. That would be difficult to fit into the existing store API, and hard to speed up with indexes. However, ASCII case folding would probably cover most of the cases people care about.
There is the issue that common-id is not specifically an AppStream ID. But it was originally added to expose an AppStream ID (e.g. this and this). I don’t think it has ever been used for any other purpose. So if ASCII case folding would help with the AppStream case, I think it seems like a good idea.
@jamesh I was looking at the snapd code yesterday, and I think, we can write the desktop files based on the common id which can remove many theming and icon related issues in both KDE and Gnome.
That’s a bit of a different issue, and wouldn’t solve the store search issue being discussed here. I’d sketched out a proposal for this a while back here:
It’s something we’d like to implement, and there has been a bit more exploration since I made that post (e.g. it turns out gnome-shell makes some assumptions about snap desktop file names, which will need to be fixed). But we haven’t started on the implementation yet.
By the way I just realized that I was mentioning the v1 API, the point applies similarly to the v2 API. To be more precise this exhibits the same issue: curl -s "https://api.snapcraft.io/v2/snaps/find?common-id=org.videolan.VLC -H 'user-agent: curl' -H 'snap-device-series: 16'
and curl -s "https://api.snapcraft.io/v2/snaps/find?common-id=org.videolan.vlc -H 'user-agent: curl' -H 'snap-device-series: 16'
don’t give the same result.