[AppStream] Unifying the AppStream IDs

[Matthias Klumpp]

2016-07-25 16:59 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
> On 25 July 2016 at 15:13, Matthias Klumpp <matthias at tenstral.net> wrote:
>> 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.
>
> What's a launcher?

A .desktop file, sorry for the unclear terminology.

>> 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.
>
> So the AppStream ID is 100% decoupled from the application ID?

What's an application-id? Is it the desktop-file-id?
In some future, maybe - in the near future I would like to keep the
one-metainfo-file-per-.desktop-file strategy, simply because
abandoning that would make AppStream fail on current Linux
distributions (we wouldn't know anymore what to installer to e.g. get
"LibreOffice Writer").

>> 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.
>
> <id>org.hughski.ColorHug</id>
> <id type="desktop">kde-ch-client.desktop</id>

I was thinking more of something like:
<launchers>
  <desktop>org.libreoffice.Writer.desktop</desktop>
  <desktop>org.libreoffice.Calc.desktop</desktop>
  <desktop>kde4-blah.desktop</desktop>
  <desktop type="default">org.foobar.Baz.desktop</desktop>
  <command>foobar --baz</command>
  <dbus interface="org.example.Test">RunApplication</dbus>
</launchers>

But I haven't put much thought into this at all yet, since this is
nothing I plan to add hastily.
Your suggestion above doesn't actually look too bad, as it preserves
some kind of backwards-compatibility.

>> 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.
>
> Define "a while"... I can't really say when we're planning the next
> rebase, but it's not going to be in the next 12 months...

I was thinking a year or so... The drawback this would have though
would be a misalignment between the spec and the actual
implementations, which is not really great. But if it would make
things better for you, then we could do something like that.

Btw, I plan to ship this massive amount of spec changes (there are
others coming up as well...) as AppStream 0.10, with 1.0 being not too
far away (but there are a few things I want to fine-tune before that,
especially I want to be absolutely sure that AppStream works well with
Flatpak and Snappy, and I want to ideally have all changes in asglib
in the spec or similar functionality in the spec. This will take a
while to do properly.)

>> 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?
>
> g_dbus_is_unique_name() suggests its not trivial:
> https://github.com/bratsche/glib/blob/master/gio/gdbusutils.c -- it's
> probably best just to use that function.

Uhhh... But it looks pretty much like what I described above -
alphanumerics, dots, hyphens and underscores :-)
I looked at a list of TLDs for proper validation, and that list is
massive, containing >> 1400 entries... Including things like .yahoo
and .accenture, .airforce and .edeka.
Let's see how to deal with that properly too - .app also seems to
exist, but nobody registered .desktop yet ^^

Cheers,
   Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/