Session suspension and restoration protocol

[Simon McVittie]

On Tue, 19 Jun 2018 at 13:56:22 +0200, Markus Ongyerth wrote:
> P.S. I just thought about this ab it more, and something else came to my mind:
> How is env passed with dbus activation? afaik the session bus does not run in 
> under the compositor, so if we aren't on wayland-0 (which can happen very well 
> in dev situations, and multi seats, and ...) we'd have to tell the client as 
> well.

The session bus can run either inside or outside the compositor. It
depends how you have designed your OS, and what you consider "the session"
to mean. Desktop infrastructure can tell the dbus-daemon what environment
variables it should pass to its child processes (but there can only be
one answer at a time).

In the terminology of
https://lists.freedesktop.org/archives/dbus/2015-January/016522.html
a "session = login session" world would have one of these:

    user session for uid 1000 (owns XDG_RUNTIME_DIR)
        \- login session c1
            \- compositor
                \- compositor-launched app
                \- session bus
                    \- D-Bus-activated app

or

    user session for for uid 1000 (owns XDG_RUNTIME_DIR)
        \- login session c1
            \- session bus
                \- D-Bus-activated app
                    \- compositor
                    \- compositor-launched app

(in the latter case you'd probably want to use
UpdateActivationEnvironment() to send the WAYLAND_DISPLAY to the session
bus)

while a "session = user session" world would have this:

    user session for for uid 1000 (owns XDG_RUNTIME_DIR)
        \- systemd --user (optional)
            \- systemd-launched app (possibly done via D-Bus)
            \- session bus
                \- traditionally D-Bus-activated app
        \- login session c1
            \- compositor
                \- compositor-launched app

(again, you could use UpdateActivationEnvironment() to send the
WAYLAND_DISPLAY to the session bus if necessary)

The Activate() method defined by the Desktop Entry Specification passes
a key:value map of arbitrary "platform data" to the activated process.
It would be reasonable to include something like
{'wayland_display':<'wayland-1'>}, meaning "use this Wayland display if
possible, overriding the environment". (However, if the app only supports
connecting to one Wayland display at a time, you're still stuck.)

> Thinking about clients that may have multiple instances, but not shared 
> sessions, e.g. some IDE with two projects opened.
> iiuc the activation would start one process, which could then either restore, 
> or open as normal, but when another project is openend, the process is already 
> running and has to start another instance.
> Over just having a single point of entry where it's started with restoration, 
> or without.

Clients with multiple instances (an IDE with a process per project) are a
better fit for a fork-and-exec design, yes.

Conversely, clients with a single instance (an IDE with one big process
that can host multiple projects each in their own top-level window,
like emacs with emacsclient, or GNOME Builder) are a better fit for an
instance-as-a-service design. Clients with a single top-level process
that manages a hierarchy of internal "helper" subprocesses, like web
browsers, are probably also a better fit for the design.

    smcv