Samsung Proposes Session Management Protocol For Wayland

[phoronix]

Phoronix: Samsung Proposes Session Management Protocol For Wayland

Samsung OSG developer Mike Blumenkrantz is proposing a new Wayland protocol for dealing with session management behavior...

http://www.phoronix.com/scan.php?page=news_item&px=Wayland-XDG-Session-Management

[davidbepo]

this is one of the things needed for me to switch to wayland

[Guest]

That sounds like something that should be handled by the compositor (KWin, Weston etc.) and not by Wayland (the protocol).

[treba]

That sounds like something that should be handled by the compositor (KWin, Weston etc.) and not by Wayland (the protocol).

Ehm it does get handled by the compositor. But probably involves client support, so it has to be in the protocol.
Of course there's the other approach (which is being discussed for gnome 4) to make sure the wayland server part simply doesn't crash. For example by splitting up that part from the rest, like window managing and compositing.

Anyhow, this sounds like a reasonable way to go

[Guest]

Ehm it does get handled by the compositor. But probably involves client support, so it has to be in the protocol.

I don't know the specifics of how Enlightenment does it but having the client know details about the compositor sounds wrong to me from an architecture standpoint. That's like a web page asking the browser about it's index in the tab list. Abstractions shouldn't depend on details and the fact that an application is rendered in a Wayland window is a detail.

[ehansin]

I couldn't answer one way or the other about this, all I know is that I hope they get Wayland right. I would love to have Linux be a more solid alternative to Windows or macOS. In Linux I see the "stack" evolving. For a good desktop experience, there needs to be good lower-level components. I have a bone to pick with all the various desktop environments, but my feeling is that if the core pieces are good enough, then there is space to really shine on the actual desktop itself. If you have crappy (or outdated) graphics/display server, audio handling, font handing/rendering (or just bad fonts), etc., etc., it doesn't matter about the desktop environment anyway. But if those core low-level pieces are solid and best in class (or equivalent), then there is opportunity to create a desktop environment that really shines. So again, I just hope whatever is done is done right, as Wayland is a core piece of the bigger puzzle.

[hiryu]

I have to wonder if this could be useful for driver updates without restarting your session entirely...

[KellyClowers]

I don't know the specifics of how Enlightenment does it but having the client know details about the compositor sounds wrong to me from an architecture standpoint. That's like a web page asking the browser about it's index in the tab list. Abstractions shouldn't depend on details and the fact that an application is rendered in a Wayland window is a detail.

Right now clients terminate themselves when the compositor disappears. There has to be support on their side to not do that...

[Terrablit]

I don't know the specifics of how Enlightenment does it but having the client know details about the compositor sounds wrong to me from an architecture standpoint. That's like a web page asking the browser about it's index in the tab list. Abstractions shouldn't depend on details and the fact that an application is rendered in a Wayland window is a detail.

That's not the point, and it's bad form to assume it is. Clients need to understand not only that the session can be recreated easily (as mentioned by KellyClowers), but there will likely be special messages needed to communicate state. Like telling the client about new buffers and endpoints, or any previously-saved/recovered state information that's useful. Pointers, handles and other stuff that pointed to the old compositor session will quite obviously be invalid if it crashes. And, while we have messages designed to pass this information on startup, they might not be well-suited to re-establishing a broken session.

Assuming that Enlightenment's approach to session management is to make the clients manage the compositor's internal state is a rather absurd assumption to make. Given it's a protocol-based system, there's going to be messages in which the two pass necessary data to quickly recover a session. Think about the necessary data required for that and and you'll be closer to the truth. Also, consider that each client will only be discussing client-specific behavior and state with the compositor.

Let's maybe go out on a limb and not assume that proposed protocol extensions are made by idiots. Especially when we haven't even bothered to look at the specifics.

[oiaohm]

That sounds like something that should be handled by the compositor (KWin, Weston etc.) and not by Wayland (the protocol).

I would rethink. Currently we have gnome, KDE, enlightnment... all doing session management differently. Most as services running in their own right.

So we already have a stack of unique protocols for talking to session management.

The current protocol include a highly useful feature of if session management service crashes and restarts applications can send back across what windows and state they in fact need.

https://xpra.org/

For x11 what the current protocol include is basically xpra. So each application can retell the compositor what they need.

This is a useful feature on embedded devices the ability to freeze application to disc and throw it out of ram and restore it latter. This opens up some very interesting power management options and the ways to free up cpu time for heavy tasks without having to restart applications from scratch afterwards.

Now extending a uniform session management could add useful features like ability to tell session that 2 windows should be grouped with each other because they are the same document and the other one is a different document. Really its not practical for application developers to write features like that while we have each desktop environment with own session management solution with unique protocol.