Bug 95129 - firm up valid application IDs (wrt. dashes)
Summary: firm up valid application IDs (wrt. dashes)
Status: RESOLVED FIXED
Alias: None
Product: Specifications
Classification: Unclassified
Component: desktop-entry (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Allison Lortie (desrt)
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-25 10:04 UTC by Allison Lortie (desrt)
Modified: 2016-04-25 10:34 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
desktop-entry-spec: allow '-' in application ids (2.90 KB, patch)
2016-04-25 10:05 UTC, Allison Lortie (desrt)
Details | Splinter Review
desktop-entry-spec: allow '-' in application ids (2.94 KB, patch)
2016-04-25 10:23 UTC, Allison Lortie (desrt)
Details | Splinter Review

Description Allison Lortie (desrt) 2016-04-25 10:04:59 UTC
The desktop entry spec is not clear on what makes a valid application ID other than to specify that it should be a valid D-Bus bus name.  Unfortunately, it describes a process for converting the bus name into an object path that assumes that '-' will never appear here.

Explicitly specify that '-' is, indeed, permitted.  Also specify how to handle this when mapping to an object path.
Comment 1 Allison Lortie (desrt) 2016-04-25 10:05:21 UTC
Created attachment 123236 [details] [review]
desktop-entry-spec: allow '-' in application ids

Up to now, the spec has not clearly specified what will happen if a '-'
appears in an otherwise-valid-looking application ID with
DBusActivatable=yes.  This leads to problems because '-' is indeed valid
in D-Bus names (which suggests that everything should work properly) but
not valid in D-Bus object paths (which suggests that it won't work).

Firm up the range of valid characters permitted in the recommended style
of application IDs (instead of just saying "reverse DNS convention").
Specifically mention that '-' is permitted here.

Specify how to deal with dashes when forming the D-Bus object path for
the org.freedesktop.Application interface.
Comment 2 Lars Uebernickel 2016-04-25 10:14:08 UTC
Comment on attachment 123236 [details] [review]
desktop-entry-spec: allow '-' in application ids

Review of attachment 123236 [details] [review]:
-----------------------------------------------------------------

Clarifying this makes a lot of sense to me. Thanks.

Note that there's another restriction: elements in D-Bus names may not start with digits, but in domains they may. For example, "de.0pointer" is not a valid D-Bus name.
Comment 3 Allison Lortie (desrt) 2016-04-25 10:23:03 UTC
Created attachment 123237 [details] [review]
desktop-entry-spec: allow '-' in application ids

Up to now, the spec has not clearly specified what will happen if a '-'
appears in an otherwise-valid-looking application ID with
DBusActivatable=yes.  This leads to problems because '-' is indeed valid
in D-Bus names (which suggests that everything should work properly) but
not valid in D-Bus object paths (which suggests that it won't work).

Firm up the range of valid characters permitted in the recommended style
of application IDs (instead of just saying "reverse DNS convention").
Specifically mention that '-' is permitted here.

Specify how to deal with dashes when forming the D-Bus object path for
the org.freedesktop.Application interface.
Comment 4 Allison Lortie (desrt) 2016-04-25 10:23:26 UTC
I've added "Components may not begin with a digit."
Comment 5 David Faure 2016-04-25 10:30:33 UTC
Sounds good to me, thanks for the clarification.

I'll adjust the KDBusAddons code, which was removing '-' characters from the object path, to turn them into '_' instead.
Comment 6 Allison Lortie (desrt) 2016-04-25 10:34:01 UTC
Attachment 123237 [details] pushed as a27043c - desktop-entry-spec: allow '-' in application ids
Comment 7 Allison Lortie (desrt) 2016-04-25 10:34:16 UTC
Thanks for the quick reviews and changes in KDE.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.