[AppStream] Unifying the AppStream IDs

[Matthias Klumpp]

2016-07-25 18:26 GMT+02:00 Simon McVittie <simon.mcvittie at collabora.co.uk>:
> On 25/07/16 16:17, Matthias Klumpp wrote:
>> 2016-07-25 16:59 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
>>> What's a launcher?
>>
>> A .desktop file, sorry for the unclear terminology.
>
> In the automotive app-management stuff I've been working on, we've been
> calling these "entry points", where one AppStream component has 0 or
> more entry points (and a desktop-application would have 1 or more).
>
> We've mainly been using "launcher" to mean the menu-like thing that
> launches entry points (.desktop files), analogous to gnome-panel or
> GNOME Shell. If anything, an entry point is a launchable, not a launcher :-)

Right - entry-point sounds a bit generic though, launchable actually
describes what it is best so far.
Fortunately, we don't need to determine a terminology for this yet,
until it is actually useful to have this data in an AppStream metainfo
file.

>>> 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 :-)
>
> You probably don't want g_dbus_is_unique_name(). Unique names are the
> things that look like :1.23, and include colons (indeed, they must start
> with one). If you want to align with D-Bus, I think you should prefer to

Jup, I looked at interface_name/name in that file, I think hughsie
meant the same :-)

> copy the syntax of either interface names or well-known bus names. Both
> of those normally look like com.example.MyProgram; the difference
> between them is that well-known bus names may contain hyphen/minus but
> interface names must not.

Yeah, this is pretty weird - do you know the reason for not allowing that?

> Note that well-known bus name and interface name components must not
> start with a digit, unlike unique name components (so you can't have
> "org.7-zip.Archiver" or even "org.7_zip.Archiver").
>
> The mangling I have been trying to encourage is that the owner of a
> domain with leading digits or with hyphen/minus (7-zip.org is a nice
> example of both) should publish apps named like org._7_zip.Archiver,
> which is ugly, but ensures that the bus name, interface name and "app
> ID" (whether that means AppStream or .desktop file) can be an exact
> match, modulo addition or removal of a .desktop suffix.
>
> I think Flatpak has been canonicalizing by treating hyphen/minus and
> underscore as equivalent when deciding what names you can own, so a
> Flatpak named com.example.My-App can own the bus name com.example.My_App.

That sounds like a good solution in Flatpak. If possible I would like
to avoid imposing the number/hyphen restrictions to AppStream IDs,
since this will complicate the way we build IDs again and would be
non-obvious to people ("why can't I use my real domain name?").
Internally, we can of course treat the IDs however we like, and we
could even have the files specifically state the D-Bus interface names
they want to own (see <provides/> -> <dbus/>)

> All D-Bus names (in all their various subtly different variations) are
> pure ASCII. Internationalized domain names are also ASCII on the wire
> (due to DNS protocol limitations), using "Punycode"; for example
> яндекс.рф (yandex.ru's Cyrillic alternate domain, according to
> Wikipedia) is spelled xn--d1acpjx3f.xn--p1ai when it appears in DNS
> packets, and I suppose they could use the D-Bus name
> xn__p1ai.xn__d1acpjx3f if they really wanted to. (But in practice I'm
> sure they'd use ru.yandex.)
>
>> 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.
>
> ICANN can (unfortunately) create new TLDs at any time, so you can't
> validate like that offline in any case.

I did this now:
https://github.com/ximion/appstream/commit/2161b3d87020f02638a888d7f4ec9760ee25a9c1

This will check if the AppStream ID is a reverse domain-name, and if
it clearly isn't one emit a validation error for anything which isn't
a desktop-application component. The desktop-app components will
instead get a warning about that, because they will need to adapt
their .desktop fiole as well and might not (want to) follow the new
spec yet.
I also check that the ID contains only alphanumeric ASCII characters,
dots, hyphens and underscores (if there is more, an error is emitted).
Additionally, I check the TLD part of the reverse domain-name against
a hardcoded list of known TLDs (excluding internationalized domain
names, and also excluding any domain name bigger than 4 characters, to
keep that list small. This means "yahoo.foobar.Baz" would currently
not be valid, so I consider dropping that filter). If the name isn't
in there, I emit an info-type hint that the ID might not be a reverse
domain name.
Info-type means that the document will validate cleanly (only errors
and warnings make the validation fail), but upstream projects can
still investigate the issue.

Does that seem reasonable?

Cheers,
    Matthias

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