[AppStream] Extensibility in AppStream

[Matthias Klumpp]

2016-07-26 23:02 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
> On 26 July 2016 at 17:57, Simon McVittie <simon.mcvittie at collabora.co.uk> wrote:
>> Richard, is there any chance of adjusting how appstream-glib represents
>> its metadata API in the XML to fit with that rule?
>
> Sure, I'd support <X-${KEY}>${VALUE}</X-${KEY}> if ximion is happy with that.

That would be better than having an inofficial tag, and also makes it
clear that these tags are not specified.
So yes, I would be fine with that.
But I still don't like it, since this stuff will only ever allow you
to specify simple key-value pairs, which will likely make people write
weird XML to achieve what they want.
I would really like to see nobody having to use those custom vendor
tags (hughsie is only doing it because he uses the XML as caching
format, which IMHO is the wrong approach).

>> I really don't want to add platform-specific API/ABI that has to be
>
>> Right; but I predict that we're fairly likely to still need them.
>
> I think a spec has to be useful in a real-world environment to be
> successful, which is why I've needed <metadata> for basically years.

All the stuff I have seen in there is wasn't very useful or could have
been achieved in other ways, e.g. the cache-id stuff is only needed
for appstream-builder - the appstream-generator doesn't require this
because it has a LMDB database as backend which stores exactly this
supplementary information. So the final XML/YAML metadata won't
contain it.

If you find anything which makes sense for the main spec, tell me and
we can add it like we did with quite a lot of other things in the
past.

>> * Android-style permissions flags, so that app installers like GNOME
>
> appstream-glib does support some <permission>-type thing for that; it
> was added before flatpak and sandboxing existed, so I think it's just
> a key-value store with nothing specified.

Right, I am waiting for Snappy and Flatpak to come up with some names
we can use for that. I also don't like the name "permissions" much,
maybe "capabilities" / "intents" is better. But this is a discussion
we will need to have as soon as Flatpak and Snappy and whatever else
will exist in future have matured enough so there is actually
something using this information and we can come up with globally
acknowledged names for capabilities and application should have.

Cheers,
    Matthias