[AppStream] Extensibility in AppStream

[Simon McVittie]

On 21/07/16 16:02, Matthias Klumpp wrote:
> Prefixing things with "x-" is the way to add non-standard spec
> extensions. The AppStream validator will ignore those when validating.

Richard, is there any chance of adjusting how appstream-glib represents
its metadata API in the XML to fit with that rule?

> As soon as things are in libappstream, I can't remove the things
> easily anymore, because there should be ABI and API stability.

I understand that, and that's why I'm keen to have an extensibility
point with an API based on strings rather than adding new C symbols,
something analogous to the C API that appstream-glib provides for its
<metadata>:

    get_metadata() -> map<string key,string value>
    add_metadata(string key, string value)
    remove_metadata(string key)

I don't mind what the precise mechanics are for namespacing those
strings - X-Vendor-SomeField, com.example.Vendor.SomeField or an
XMLNS-style URI would all be fine - but I suspect we'll need one sooner
or later.

> You could experiment with things by carrying downstream patches and
> upstream them.

I really don't want to add platform-specific API/ABI that has to be
maintained as a fork forever; I'd much prefer to use extension points
within upstream libraries/tools without forking them. For instance,
where needed we can introduce special-purpose metadata for launchable
apps (entry points) in GDesktopAppInfo by looking up an
X-Vendor-Whatever string, the same way GNOME does for things like
X-GNOME-Autostart-Phase. The extensibility I'm looking for here is
analogous.

> Some company-internal extensions would never be supported in the
> upstream spec

Right; but I predict that we're fairly likely to still need them. If
there's a well-defined way for these user-defined fields to pass
through, such that (for example) generic AppStream tools will merge them
in a predictable way when combining upstream-XML documents into a
distribution-XML document, then we can work with that.

> the same applies to things which aren't metadata (e.g.
> stuff that influences how the application works, or things like build
> recipes).

Where are you drawing the line between metadata (in-scope for AppStream)
and non-metadata (out of scope)? Here are some topics that I'm currently
looking at:

* Android-style permissions flags, so that app installers like GNOME
  Software can tell the user before installing an app whether it is
  going to demand access to sensitive features like geolocation,
  app-store curators can tell the same thing during review, and the
  implementation of the sensitive feature can reject requests that
  aren't consistent with what the app declared ahead of time

* Declaring what D-Bus names it's going to take ahead of time, so that
  app installers like GNOME Software can check for conflicts,
  app-store curators can reject apps that attempt to provide someone
  else's D-Bus name unless that name is one that the app has a
  legitimate reason to use (like org.mpris.MediaPlayer2.ThatApp), and a
  sandboxing implementation can prevent acquiring a name that isn't
  consistent with what was declared

* Declaring PulseAudio audio roles ahead of time, so that app-store
  curators can reject apps that use high-priority audio roles like
  "phone" with no legitimate reason to do so, and a PulseAudio plugin
  or a sandboxing implementation can reject audio streams that use an
  audio role that the app doesn't have permission to use

Are those in the scope of AppStream, because they're things you would
want to know during submission to an app-store and (in at least some
cases) during installation from an app store, or are they out-of-scope?

> A specification should really not define some field which
> contains random stuff which downstream consumers may or may not
> support and which we do not (and can not) validate for correctness at
> all.

I'm not sure that I agree with this. .desktop files, email and HTTP all
have a convention to do so (X-Vendor-Whatever), and so do HTML5
(microdata), various D-Bus APIs (e.g. "Hints" in o.fd.Notification), and
even XML (anyone can define elements under their own XMLNS). As long as
there's graceful degradation (not supporting a property is equivalent to
it being absent) and a path for adopting extensions into the formal
spec, it's a useful tool in the design toolbox.

> It would be helpful to see some concrete issues you might be facing

I'll bring up specific concrete features on this list as they come up,
but I wanted to start the conversation about extensibility in advance,
because I suspect that we'll eventually run into things that either
aren't of interest for the "core" AppStream spec, or need to be
prototyped and discussed for a while before we can judge whether a
proposal for the "core" spec is of suitable quality or not.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>