The session management protocol allows to restore the previous state of a surface. This can be useful for applications wishing to restore their previous window position or compositor restarts.
Unfortunately, this change doesn't implement the full version of the upstream protocol spec. A couple of changes were made to reduce the number of potential corner cases and to simplify the server side part of the protocol.
In order to start using the extension, the compositor has to decide how the session data is stored. No assumptions are made about the underlying session storage format. Theoretically, a piece of shared memory can be used to back the storage if the compositor has some sort of crash resilience mechanism.
Once the session storage format has been chosen, the compositor can start reading and writing session data by using two methods
The XdgToplevelSessionV1Interface class imposes no limitations on data that can be stored in the session. If an application asks to remove all session data associated with a particular surface or session, the session storage will be cleaned up automagically without involving the compositor. However, it is still up to the compositor to decide when the session storage has to be flushed to the disk.