RFC: Allow host apps to register themselves

[jadahl]

For host apps, we currently require applications to run inside a cgroup with a name that allows xdg-desktop-portal to derive an application ID from it. This does not work reliably, and while the situation can improve, it's unlikely to ever be fool proof, as it in theory requires every potential piece of software that launches other applications to know how to launch it in a compatible way.

Cgroups is also a Linux specific API, which is problematic from a *nix wide portability perspective.

To address this, introduce a host-only portal API that allows applications to register their D-Bus connections, associating them with an application ID. This moves back the burden of associating an application with an application ID back to the application itself, instead of the application launcher.

Applications calling this overrides any applicion ID derived from the name fo the cgroup the application runs inside.

---

I'm not saying we should do this, but perhaps it is something we should consider doing. Relying only on cgroups is a noble idea, but it hasn't worked well so far, and while it's possible that at least a majority of cases can be handled by peeking at it and deriving the application ID, it's also likely that there will always be cases where it won't work, without any way for applications to get themselves to work.

Some downsides include:

• Giving up on the idea to always have host apps run in a properly named cgroup, at least for any portal purposes. It's a good end goal in itself, but hard to say how reliable it can ever be.
• Yet again more than one way to get the same piece of information, as in we're creating another mess for ourself.

Some upsides:

• Applications can now fix themselves. They can't realistically do that by relying on cgroups.
• Not Linux specific. While sandbox engines probably are, it's a good end goal to have portal API's be as widely adopted as possible.

[ebassi]

Applications can now fix themselves. They can't realistically do that by relying on cgroups.

As much as I admire your optimism, I have a pretty hard time believing apps will "fix themselves" by calling a D-Bus API (or using libportal) for the unsandboxed case. You're still asking application developers to deal with this case. Might as well ask them to call:

setenv ("XDP_PROP_application_id", "com.example.App");

in their main(), like Pulseaudio requires, and then have every single portal-aware library check for that environment variable.

[swick]

One could equally argue that apps only have to call StartTransientUnit("app-none-{appid}", pid()) in its main but that also hasn't happened so far...

[jadahl]

As much as I admire your optimism, I have a pretty hard time believing apps will "fix themselves" by calling a D-Bus API (or using libportal) for the unsandboxed case. You're still asking application developers to deal with this case. Might as well ask them to call:

For apps that wants to support running non-sandboxed that uses libportal or ashpd could perhaps use API like xdp_portal_set_fallback_app_id(). No need to go via env vars for that.

For apps that interact directly with the portal using D-Bus it seems like a trivial thing to make just another method call before anything else.

One could equally argue that apps only have to call StartTransientUnit("app-none-{appid}", pid()) in its main but that also hasn't happened so far...

Using StartTransientUnit() is a bit problematic since it might already be in a proper unit, not to mention it's systemd specific, which might hinder adoption of portal APIs as "universal". I also imagine app developers are more hesitant to start to become self-service managers like that, compared to just passing a bit of metadata.

[swick]

Using StartTransientUnit() is a bit problematic since it might already be in a proper unit

One could check that and skip StartTransientUnit().

Anyway, I do agree that calling one more portal helper function or calling one more dbus method when one wants to interact with portals shouldn't be much of an issue.