Session suspension and restoration protocol

[Markus Ongyerth]

On 2018/6月/19 01:39, Simon McVittie wrote:
> 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)
Sounds racy if there's more than one session on the same bus.
Locking ourselves into a single-compositor setup is quite annoying. And IMO we 
shouldn't rely on changes that affect the entire system setup.
It would at the very least increase the hurdle to get new devs, maybe even 
deter existing devs from touching any feature there.
> 
> 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.)
I wonder if it's that much better to define wayland specific variables on that 
end, than it is to specify dbus specific things on this end.
In the optimal case they would be largely independant.
> 
> > 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.
Those have their own private IPC, and as far as I have seen, every application 
supports launching it and passing the arguments over an internal channel.  
Which might be configured to not do this, or evaluate over some other env 
(e.g. WAYLAND_DISPLAY) if it should do that.
> 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.
There's also an issue with the protocol design here. We can only have one 
restoration id per wayland client. So this needs to be changed for those 
either way.
> 
>     smcv
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180619/66ea6a23/attachment.sig>