Session suspension and restoration protocol

[Roman Gilg]

On Mon, Jun 18, 2018 at 6:01 PM Simon McVittie <smcv at collabora.com> wrote:
>
> This document might be useful for the D-Bus side:
> https://dbus.freedesktop.org/doc/dbus-api-design.html

Hi Simon, thanks for the link. I have read it. Was a good D-Bus
overview/introduction I have looked for already for quite some time.
Wondering why I never found it before. Should enable me to misuse
terminology less often. Thanks for the numerous corrections you did on
that in your reply. I won't reply to all of them here, but will
integrate them if there is a final proposal.

> Do you intend the D-Bus side of the protocol to be equally useful to
> X11 apps, or is this a Wayland-only thing?

I have only thought about Wayland apps until now, because for X11 /
Xwayland in Plasma we have XSMP support. But I'm not against having
the mechanism work for X11 apps as well as a replacment for XSMP since
GNOME doesn't use it at the moment and thought it was lacking. So yea,
if it would work for X11 apps as well, that's fine with me and I will
try to help make it happen.

>
> >         and the method being called by the
> >         compositor on this interface is simply called 'restore'
>
> D-Bus method names are conventionally in camel-case, so 'Restore'.
>
> When we discussed this on #gnome-hackers we were talking about doing
> restoration by passing the restored session ID as platform_data to the
> Activate method defined by
> https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus
> which would mean that for trivial/stateless apps, it would be enough to
> ignore it and just start up, which DBusActivatable implementations like
> GtkApplication will already do. Is there a reason why you've opted to define
> a new method instead?

I think it makes sense to have a separate method, because a client can
dbus-activate with the protocol any dbus-activatable app. Imagine a
rogue client tries to dbus-activate an app, which is not written to
use this extension but provides the Activate method. The compositor
tries to dbus-activate it and gets no feedback that this was an
operation not doing what it supposed to do. If there is no Restore
method, I assume D-Bus would tell it so. The compositor can then show
this information to the user.

In this sense the protocol should be extended with the information
that the Restore method should also return an error, if the
restoration id is not found. A rogue client would that way also not be
able to silently start a different client, that is supports the
protocol (for that to make it secure the restore IDs should be
generated through a hash function though).