[AppStream] Unifying the AppStream IDs
Matthias Klumpp
matthias at tenstral.net
Mon Jul 25 14:13:57 UTC 2016
Hey!
After some more thinking about this, I think that I really want to
make this change, even if it means some slight breakage.
I have had this on my "issues with the spec" list for a while, and
learned at the Snappy sprint that it actually makes the AppStream
story more confusing to explain ("why isn't just a reverse-URL-id
enough?"), and also assigning meaning to the ID in a weird way doesn't
make too much sense.
For example, there might even be applications installing multiple
launchers in future, which we can not represent with AppStream right
now, but which is a thing Snappy supports.
So, I really really want to strip the meaning of "this is a .desktop
file-id" from the AppStream component ID. This will also resolve
issues like we had with the kde4 prefix in the past.
What I will add to libappstream is a function to the the
.desktop-file-id from an AsComponent, which software centers can use
to launch an application.
Furthermore, streamlining the component-ID story will make the spec
much simpler. The only breakage with this will happen if the AppStream
clients don't know about this change yet, which is why I will probably
tie it to also using "desktop-application" as type.
That way, stuff won't show up on the SC if it uses the new schema.
People in RHEL will likely test their apps and spot the issue that
way. If you want, I can also defer updating all documentation for a
while, so we can transition at a later time.
Yes, this sucks and is really annoying, and while AppStream-IDs being
a central concept is a good reason to do them right, it is also a good
reason not to change them. But I genuinely believe that this change is
important for the project and will have a very very positive effect in
future, so I would really like to make it.
With this change, all "impurities" in the AppStream spec are gone now
too, so I can almost say for certain that this will be the last major
change done in the spec for years.
(a few minimal weirdnesses remain, such as the "mimetypes" tag not
being in "provides", but that's really not worth changing, as it gains
you absolutely nothing).
I checked the AppStream data pools, so far almost nothing follows the
correct AppStream ID schema, except for thing Richard or I are
directly involved with. So I will adjust the validator to validate the
ID more strictly.
Which brings me to a question: Should we limit the AppStream-ID to
being alphanumerical and dash/dot/underscore? That would rule out some
Chinese TLDs and e.g. URLs with umlauts, but will ensure everyone can
type the ID. Does DBus allow unicode for interface names?
Kind regards and sorry for the inconvenience,
Matthias
More information about the AppStream
mailing list