Ideas for Session Management in GTK/GNOME

Design requirements

• Handle interactivity
  • confirm actions with the user
  • allow inhibition of shutdown
• Security
  • handle sandboxed applications
  • race-free
• Save state on quit
• Restore state on launch
• Handle automatic application shutdown policies
  • memory pressure
  • CPU pressure
  • OS updates
  • application updates
• Backward compatibility/null backend
  • system should be able to cope with existing apps
  • prevent data loss

Non-goals

• Standardisation
• Replace XSMP/existing session management functionality
• Portability

High level design

• Application start up
  • First time/initial state
• State save notification

  • Transform current state into a GVariant a{sv}

    • No schema needed; the application must know how to serialize and deserialize its internal state, and resolve changes
  • The application does not save the state, to avoid races and blocking
  • Each state is stored alongside a timestamp, a "commit id", and a parent "commit id"

    • e.g. .var/session/com.example.Application/aa/bbccddeeff001122334455/state.gvdb

      • parent: aabbccddeeff001122334444

      • timestamp: 2017-02-21T16:22:23+0000

• Load state
  • Implicit
    • part of the platform-specific data passed when activating an application
    • easy to implement
    • harder to deal with previous states
  • Explicit
    • additional API to be called when activating an application
    • adds more API
    • allows more control on which states can be recovered