Session Management Proposal

Mark Finlay sisob-lists at tuxfamily.org
Sun Dec 28 18:39:44 EET 2003


Hi Ray,

I've very ignorant of all this, but It's great to see some movement in
this area. I would just like to draw attention to the following bug
because AFAIK it was problematical due to the limitiation of the XSMP
spec and so might be relevant:

http://bugzilla.gnome.org/show_bug.cgi?id=70710

Thanks

Mark

On Sun, 2003-12-28 at 13:49, Ray Strode wrote:
> 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 at 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>

-- 
Mark Finlay 
Computer Science Student

E-Mail:	sisob_AT_tuxfamily_DOT_org
Jabber:	sisob_AT_jabber_DOT_org
Blog:	http://sisob.tuxfamily.org
 	http://advogato.org/person/sisob





More information about the xdg mailing list