Session Management Proposal

[Ray Strode <halfline hawaii rr com>]

Hi,

I'm currently working on improving the session management situation in
GNOME.[1] I've adopted Havoc's msm module from GNOME CVS and am working
on making it a viable replacement for the current gnome session manager.

The XSMP spec is lacking some features that would be useful for desktop
session managers.

   1) Session managers have no way of knowing localized names for
      their clients.  This means that there is currently no nice way
      for session managers to present clients to the user (in error
      messages, splash screens etc).  Current session managers work
      around this by employing internal SmProgram mapping hacks, but
      that is clearly suboptimal.

   2) It would also be nice if each client told the session manager a
      preferred icon name (again for splash screens, etc).

   3) Some desktop environments have certain programs which provide
      integral functionality for the environment's proper operation.
      These programs need to be treated specially.  For instance, for
      most desktop environments the window manager should probably be
      the first program started on login.  Also, other fundamental
      programs like panels, desktop icons, etc., should probably be
      loaded before normal applications.  Furthermore, if for some
      reason a restored session is lacking one or more of these
      fundamental programs then it would be a good thing if the
      session manager could optionally start them up.

      The easiest way to solve these problems is to have each client
      tell the session manager, e.g. "I'm a window manager" or "I'm
      just a normal application" (or whatever).

   4) Also, users may want to control what order certain programs in
      their desktop are loaded on login.  Some session managers
      implement a Priority property where programs of lower priority
      get loaded first, which seems like a reasonable solution.

Furthermore, in the past it was agreed that parts of the XSMP should be
simplified/reinterpreted.[2]  I think there is enough to be done that
this stuff should be formally standardized.  Attached is an initial
draft.  I've also posted it online at http://www.grokthecruft.org/dsme/
If everyone agree that this document is useful, I would like to get it on
freedesktop.org.

Open Questions:
   * The document uses a _NET_ namespace for the properties.  Is that
     okay, or should something else be used?
   * Are there enough role types?  Are there too many?  If it seems
     like more will be needed, then the property may have to change to
     ARRAY8 instead of CARD8.
   * The proposal currently says that the discard command should be
     run on /all/ clients following a SaveYourself message with Global
     save type.  Would it be better to only run the discard command of
     non-spec-compliant clients?  This would mean adding some property
     to the documents for clients to set that says,  "I'm dsme
     compliant".
   * The proposal currently says that users should get involved
     whenever there is a SaveYourself message with Global save type
     (e.g. "Do you want to save 'Foo.bar'?").  Would it be better to
     skip those messages if fast is set?  I'm thinking of the case
     mentioned in the XSMP where the power is about to go out and the
     UPS is trying to shutdown quickly before the power gets cut.  I'm
     not sure if automatically saving all open documents without
     asking the user is less evil than not shutting down at all
     because the shutdown is waiting on a confirmation dialog to
     close, but if it's decided that automatically saving all
     documents is the desirable thing to do, then we should add
     something to the spec about it.  Note there is some potential for
     abuse because a broken/malicious program could have every open
     document on the desktop saved right under the user's nose whether
     the user wants all the documents saved or not.

Comments, suggestions, and additions appreciated.  

Thanks,
--Ray Strode

[1] 
http://mail.gnome.org/archives/desktop-devel-list/2003-April/msg00090.html
[2] 
http://mail.gnome.org/archives/gnome-hackers/2001-December/msg00004.html
<?xml version="1.0"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd";>
<article id="index">
  <articleinfo>
    <title>Desktop Session Management Extensions</title>
    <releaseinfo>Version 0.5</releaseinfo>
    <date>28 December 2003</date>
    <authorgroup>
      <author>
	    <firstname>Ray</firstname>
	    <surname>Strode</surname>
        <affiliation>
            <address>
              <email>halfline hawaii rr com</email>
            </address>
        </affiliation>
      </author>
    </authorgroup>
  </articleinfo>

  <sect1 id="overview">
    <title>Overview</title>
    <para>
      The X Session Management Protocol (XSMP) specification
      introduces a protocol between a session manager and its
      clients.  The protocol gives the session manager control
      over when clients are started, stopped, and told to save
      and restore state.  While the basic protocol presented in
      the XSMP specification is useful, desktop environments
      require certain features not specified in the XSMP to be
      fully functional.
    </para>
    <para>
      This document serves to extend, clarify and when necessary
      override the XSMP for improved session management within
      desktop environments through the Desktop Session Management 
      Extensions (DSME).  
    </para>
  </sect1>
  <sect1 id="definitions">
    <title>Definitions</title>
    <variablelist>
      <varlistentry>
	    <term>Active Session</term>
        <listitem>
          <para>
            An <firstterm>active session</firstterm> is the
            collection of application instances currently loaded
            and available to the user.  
          </para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term>Application-specific State</term>
        <listitem>
          <para>
            One type of state associated with an application
            instance is <firstterm>application-specific
            state</firstterm>, which is information about the
            number of currently opened windows, what documents
            are open, and other information that is important for
            presenting to the user a consistent interface across
            login sessions.
          </para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term>Client</term>
        <listitem>
          <para>
            In the context of application-session manager
            interaction, a <firstterm>client</firstterm> is an
            application.  It connects to the session manager,
            identifies itself, and listens for commands (See the
            XSMP).
          </para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term>Desktop Environment</term>
        <listitem>
          <para>
            For this document a <firstterm>desktop
            environment</firstterm> is a collection of integrated
            applications and libraries written to provide an
            intuitive interface to the computer for users.
            Commonly, desktop environments will include panels,
            desktop icons, and window managers.
          </para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term>Desktop Session Manager</term>
        <listitem>
          <para>
            A <firstterm>desktop session manager</firstterm> is a
            session manager (as defined by the XSMP) that is
            designed for managing clients in a desktop
            environment.  Desktop session managers are usually
            written specificly for a particular desktop
            environment and interact with users using facilities
            provided by that desktop environment.
          </para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term>Document-specific State</term>
        <listitem>
          <para>
            One type of state associated with an application
            instance is <firstterm>document-specific
            state</firstterm>, which is the currently open
            documents.
          </para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term>Session</term>
        <listitem>
          <para>
            A <firstterm>session</firstterm> is a collection of
            saved instances of applications.  Each application
            instance has saved state that is specific to the
            session.  The session manager controls which session
            is loaded and made active on login by some
            implementation specific means.
          </para>
        </listitem>
      </varlistentry>
    </variablelist>
  </sect1>
  <sect1 id="identification">
    <title>Client Identification</title>
    <para>
      The XSMP provides mechanisms for clients to identify
      themselves to the session manager, but the mechanisms
      provided only give low-level representations of the clients.
      There is no appropriate means of displaying the client to
      the user.  This section seeks to provide a means from
      which a desktop session manager can represent clients to
      the user through both localized client names and graphical
      icons.
    </para>
    <para>
      Some desktop environments have certain programs which provide
      integral functionality for the environment's proper operation.
      These programs need to be treated specially.  This section
      also seeks to provide a means for clients to identify
      themselves as special.
    </para>
    <sect2 id="client_name">
      <title>Localized Client Names</title>
      <para>
        Clients that support the DSME should set the "_NET_Name"
        property to a preferred human-readable, localized
        application name encoded in UTF-8.  "_NET_Name" is an
        ARRAY8 property.
      </para>
    </sect2>
    <sect2 id="client_icon">
      <title>Client Icon</title>
      <para>
        Clients that support the DSME should set the "_NET_Icon"
        property to a preferred icon name, which should be looked
        up by the desktop session manager using the procedure
        described in the Icon Theme Specification.  "_NET_Icon"
        is an ARRAY8 property.
      </para>
    </sect2>
    <sect2 id="client_role">
      <title>Client Role</title>
      <para>
        Clients that support the DSME may set the "_NET_Roles"
        property to reflect their roles in the desktop
        environment.  If a client chooses not to set the
        "_NET_Roles" property the desktop session manager should
        assume the client has an implicit role of
        "_NET_RoleNormal".  "_NET_Roles" is a CARD8 property.  A
        client can specify more than one role by performing a
        bitwise AND operation on the possible role values:
        <itemizedlist>
            <listitem>
                <para>
                    _NET_RoleNormal (0x0).  All clients that do
                    not set any other role may set this role.
                    A client with only this role set should not be 
                    treated specially by the session manager.
                </para>
            </listitem>
            <listitem>
                <para>
                    _NET_RoleWindowManager (0x1).  Window managers
                    must set this role.  Desktop session managers
                    must only allow one client per session with
                    this role set.  In the event that more than one
                    client sets this role during login then the
                    client with lowest priority should be loaded.
                    If a client attempts to register with the
                    session manager in the middle of an active
                    session and another client is already running
                    with this role set, then the desktop session
                    manager should send a "Die" message to the
                    newer client.  If a session manager detects
                    that a session is lacking a client with this
                    role set, then it may optionally start a
                    suitable client.
                </para>
            </listitem>
            <listitem>
                <para>
                    _NET_RoleDesktopManager (0x2). Programs that
                    take control of desktop handling (like some
                    file managers) must set this role. Desktop
                    session managers must only allow one client
                    per session with this role set.  In the event
                    that more than one client sets this role
                    during login then the client with lowest
                    priority should be loaded.  If a client
                    attempts to register with the session manager
                    in the middle of an active session and
                    another client is already running with this
                    role set, then the desktop session manager
                    should send a "Die" message to the newer
                    client.  If a session manager detects that a
                    session is lacking a client with this role
                    set, then it may optionally start a suitable
                    client.
                </para>
            </listitem>
            <listitem>
                <para>
                    _NET_RolePanel (0x4).  Panels must set this 
                    role.  If a session manager detects that a
                    session is lacking a client with this role
                    set, then it may optionally start a suitable
                    client.
                </para>
            </listitem>
            <listitem>
                <para>
                    _NET_RoleDesktopComponent (0x8).  All
                    resident components of the desktop not
                    specified by other other role types in this
                    document should set this role.
                </para>
            </listitem>
            <listitem>
                <para>
                    _NET_RoleSetup (0x10).  Programs that load
                    user preferences (like desktop backgrounds,
                    audio settings, etc) should set this role.
                </para>
            </listitem>
        </itemizedlist>
      </para>
    </sect2>
  </sect1>
  <sect1 id="load_order">
    <title>Client Load Order</title>
    <para>
      The order in which clients are started on login is often
      important for a proper user experience.  For instance,
      under normal circumstances the window manager needs to be
      loaded before clients with managed windows in order to
      prevent the flickering of window decorations being added to
      already mapped windows.  Also, other intrinsic components
      of the desktop should normally be started before user
      applications.  This section seeks to provide a mechanism
      for controlling the order in which clients are loaded on
      login.  This section does not address situations where the
      user is already logged in and there is an active session 
      loaded.
    </para>
    <sect2 id="client_priority">
      <title>Client Priority</title>
      <para>
        Clients that support the DSME may set the "_NET_Priority"
        property to reflect when they would like to be launched
        on user login.  "_NET_Priority" is a CARD8 property.
        Clients that set this property to low values should be
        started before clients that set this property to higher
        values.  If a client chooses not to set this property,
        then the session manager should assume an implicit
        priority for the client based on the client's role:  
        </para>
        <informaltable>
            <tgroup cols="2">
              <thead>
                <row>
                  <entry>Client Role</entry>
                  <entry>Implied Client Priority</entry>
                </row>
              </thead>
              <tbody>
                <row>
                  <entry>_NET_RoleWindowManager</entry>
                  <entry>10</entry>
                </row>
                <row>
                  <entry>_NET_RoleSetup</entry>
                  <entry>20</entry>
                </row>
                <row>
                  <entry>_NET_RoleDesktopManager</entry>
                  <entry>30</entry>
                </row>
                <row>
                  <entry>_NET_RolePanel</entry>
                  <entry>40</entry>
                </row>
                <row>
                  <entry>_NET_RoleDesktopComponent</entry>
                  <entry>40</entry>
                </row>
                <row>
                  <entry>_NET_RoleNormal</entry>
                  <entry>50</entry>
                </row>
              </tbody>
            </tgroup>
        </informaltable>
        <para>
          In the event that more than one client sets this
          property to the same value the order that these
          clients are loaded is undefined.  However, the desktop
          session manager may choose to look at each client's 
          role in determining which client to load first.
        </para>
    </sect2>
  </sect1>
  <sect1 id="session_saving">
  <title>Session Saving</title>
  <para>
    Often individual application instances in desktop
    environments will have two distinct types of state.  The
    first type of state is application-specific state and the
    other is document-specific state.
  </para>
  <para>
    Application-specific state is information about the
    number of currently opened windows, what documents are open,
    and other information that is important for presenting to the
    user a consistent interface across login sessions.  This type
    of information is important for a seamless user experience,
    but it is not the type of information that users
    should be able to collectively save or discard on a 
    per-application basis.
  </para>
  <para>
    When a user is done using the computer, if that user chooses
    to save the active session, then the application-specific
    state of all currently running application instances should
    be transparently saved for the user.  On the other hand, if
    the user chooses not to save the current session on log out,
    then the application-specific state of all currently running
    application instances should be discarded and when the user
    logs in again the most recently saved session and all its
    associated application-specific state should be loaded.
  </para>  
  <para>
    While application-specific state should be handled
    transparently for the user, document-specific state should
    involve the user.  Document-specific state is the actual open
    documents themselves.  Document-specific state is much more
    tangible to the user than application-specific state because
    users are accustomed to directly controlling what goes into
    their documents.  This control includes, for instance, what
    gets typed into the documents, but more importantly for this
    section, when the documents are saved.
  </para>
  <para>
    When the user is done using the computer and attempts to log
    out, all open and unsaved documents should be optionally
    saved or discarded on a per-document basis based on
    individual decisions from the user.  This process should
    happen regardless of whether the user chose to save the
    active session or not.
  </para>
  <sect2 id="saveyourself_semantics">
    <title>"SaveYourself" Message Semantics</title>
    <para>
      When desktop session managers send the "SaveYourself"
      message to clients the "Local" save type indicates that
      clients must save their application-specific state.  The
      "Global" save type indicates that clients must save their
      document-specific state.  In the event that save type is
      "Both" the session manager should first save
      document-specific state and then save application-specific
      state.  As stated previously, application-specific state
      should be saved without interaction from the user and
      document-specific state should be saved or discarded on a
      case-by-case basis determined by the user.  Therefore, if
      the save type of a "SaveYourself" message is "Global", then
      desktop session managers must ensure that the interact
      style for the message is "Any".    
    </para>
    <para>
      When the user is logs out, the session manager will only
      send a "SaveYourself" message to all clients. If the user
      chooses to save the active session, then the save type
      should be both.  Otherwise the save type should be
      "Global".
    </para>
    <para>
      While a DSME-compliant client must only save
      application-specific state if it receives a "SaveYourself"
      message with the "Local" or "Both" save type, it is
      possible that non DSME-compliant clients will save
      application-specific state for the "Global" save type.  For
      this reason, the session manager should run the
      "DiscardCommand" commands of all relevent clients following
      any "SaveYourself" message with save type "Global".  If the
      "SaveYourself" message was the result of a
      "SaveYourselfRequest" message with global set to "False"
      then the only relevent client is the client that initiated
      the "SaveYourselfRequest" method.  In all other cases, the
      "DiscardCommand" command of every client should be run.
    </para>
  </sect2>
  </sect1>
  <appendix id="changes">
    <title>Change History</title>
    <formalpara>
      <title>Version 0.5, 28 December 2003, Ray Strode</title>    
      <para>
      Initial Draft.
      </para>
    </formalpara>
  </appendix>
</article>