This is required when using SNI in sandbox (e.g. in flatpak) where the pid starts from 1,
usually it is 2 (the first one is bwrap) and this can theoretically cause collision with
already registered services. Also with using app name instead of pid we know in advance
what the service name will look like and we can give the sandboxed app access to it, which
is not possible when using pid as the name is not known until the app is started.
Details
Details
Diff Detail
Diff Detail
- Repository
- R289 KNotifications
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
This comment was removed by mart.
Comment Actions
are we sure applicationname is unique? what about of multiple instances of the same application?
Comment Actions
Use applicationName() instead of applicationPid() only for sandboxed applications
This still doesn't make the service name unique, but at least there won't be collision between
instances running outside the sandbox. Unfortunately I can't think of anything else to use as
we need the dbus service name predictable so we can allow access to it for the sandboxed app.
Comment Actions
definitely better!
i don't know whether we can afford to change it in any way outside the sanbox and not break things..
it may make sense to use applicationName-pid at least inside the sandbox, maybe outside as well if affordable?
(so you would have applicationName-1 applicationName-2 etc in the sandbox which still make sense
Comment Actions
Using applicationName-pid you cannot guarantee the pid will be always 1 or 2, you can have e.g a special launcher for an app doing some stuff and then you end up with much higher pid.