Re: Session Management Proposal
- From: Mark Finlay <sisob tuxfamily org>
- To: Ray Strode <halfline hawaii rr com>
- Cc: xdg-list freedesktop org, gnome-hackers gnome org, hp redhat com, mark skynet ie, ettrich kde org
- Subject: Re: Session Management Proposal
- Date: Sun, 28 Dec 2003 16:25:23 +0000
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 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
