Samsung Proposes Session Management Protocol For Wayland

[TheBlackCat]

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.

Something as complex as a display server is going to crash at times.

[Guest]

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.

I haven't considered that use case but I guess it makes a lot of sense. Thanks for pointing it out.

[raster]

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.

Did you read the extension details? You should. It doesn't involve the client knowing "details about the compositor" any mroe than any other part of wayland protocol. It's actually very very simple. Compositors assign a UUID to client surfaces when they first are created. If the client sees the connection to the compositor die, it tries to reconnect (maybe every 0.2 seconds or something). When it reconnects it connects and says "hi - this surface WAS this UUID before" when it re-creates the surfaces via protocol ... and then the compositor can know which client that one was and look up client info in a safe store of data (eg a small data file on a ramdisk or normal disk) and then the COMPOSITOR can restore state to the right size, position, stacking, virtual desktop etc. etc. etc.

it's just a simple "tag resources with UUIDs that can last across execution sessions". this happens to also allow sessions to recover if the client exits or crashes too... if the client can store state and rebuild... it can get its windows into the same state they were before thanks to the same compositor-side recovery logic.

this also helps you do things like suspend processes to disk entirely (like hibernate images per process - the kernel supports this feature) and then unhibernate them. the problem is CONNECTIONS to other services like the display or any daemon have to be re-connected because these sockets have to die as the compositor may restart or the whole os even reboot in between. so you need reconnect logic... and the above session recovery stuff can then solve this problem too. just pretend the compositor crashed from the application's side of things.

[raster]

Something as complex as a display server is going to crash at times.

it's not just crash handling. it also allows upgrading on the fly. have a bug in it? install update, restart display server, and state comes back as it was before. you don't lose you session to do an upgrade/update.