The future of session management in GNOME

[Dan Winship <danw novell com>]

In the last year or so, it's become fashionable to suggest ripping
XSMP out of GNOME and moving to a new, improved, simpler, presumably
dbus-based session management system. I'd like to argue that that's a
bad idea, and we should fix gnome-session and GnomeClient while still
sticking with XSMP.

Why don't we want to ditch XSMP?

	* The client side of the protocol is already implemented by
	  most GNOME and KDE apps, and many non-GNOME non-KDE apps.
	  The server side of the protocol is implemented by both GNOME
	  and KDE, and some other desktop environments as well. If we
	  change to a new protocol, we either lose interoperability,
	  or we have to keep doing XSMP too for compatibility (both
	  client and server side) for a long time.

	  Notably, to make a plausible argument for shifting to a new
	  protocol, we'd have to at least get KDE interested in it,
	  and they just had a SOC student implementing cool new
	  XSMP-based features in ksmserver[1]...

	* XSMP does a number of useful session-managey things (logout
	  notification, logout cancellation, specifying apps that
	  should be restarted right away if they crash, specifying
	  commands to run at logout, etc) which we currently have no
	  other way of doing, so we'd be forced to reinvent half of
	  XSMP if we ditched it.

	* Some of the old arguments for ditching XSMP are less
          relevant now that we have the fdo autostart spec (although
          integrating XSMP and autostart together more tightly would
          still be good).

	* While XSMP does have lots of annoying bits, the basics are
          well-understood (more so now than when gnome-session and
          GnomeClient were written). Many of the bad aspects of
          gnome-session are just gnome-session bugs / implementation
          decisions, not intrinsic problems with XSMP.

This doesn't mean we have to expose users to the full range of XSMP
possibilities (eg, multiple independently-resumable saved states). We
just decide what functionality we want to offer, and use XSMP to get
it (and extend XSMP where it doesn't do what we want, as we already
have).


So here's how I imagine the new-and-improved GNOME session manager
working:

	* The basic behavior is just the autostart spec; at login, the
	  session manager starts .desktop files from the system and
	  user autostart dirs. The "default session" will just be the
	  contents of the system autostart dir(s) (not a separate
	  session-manager config file), and the failsafe session will
	  be a second directory containing a smaller set of desktop
	  files.

	  The system and user autostart items will be merged together
	  in some useful/clever way, probably involving a "Priority"
	  property a la gnome-session, and some way to indicate that
	  some apps want you to wait for them to register before
	  starting any other apps (ie, don't let apps map windows
	  until the window manager is running). There will also be
	  some sort of lockdown available, although I don't know
	  exactly how that will work.

	  There might also be something like
	  X-KDE-autostart-condition, where the .desktop file can
	  specify a GConf key or something to check before starting
	  the app (eg, only start vino-server if
	  /desktop/gnome/remote_access/enabled is TRUE).

	* XSMP-based saved sessions will be implemented as a thin
	  layer on top of this. When you save application state (at
	  logout or otherwise), the session manager will write out the
	  relevant XSMP properties for the app to a new "[Session
	  Management]" section of its .desktop file in ~/.autostart.
	  (If you save the state of an app that wasn't previously
	  autostarted, it will create a new .desktop file for it. To
	  help the session manager out here, the new client API will
	  set an XSMP extension property pointing to its .desktop
	  file, which the session manager can then use as a baseline.
	  If the client doesn't set that property, the session manager
	  could use libgnomemenus to hunt down the .desktop file
	  itself, although that might be dumb.)

	  So, copying a .desktop file into your ~/.autostart directory
	  would be exactly the same as having that app register itself
	  via XSMP with the RestartCommand and CloneCommand being the
	  .desktop file's Exec line, and the RestartStyleHint being
	  SmRestartAnyway.

	  Storing all of the session state in a single location/format
	  will help fix some of the current SM/autostart integration
	  bugs. (Eg, the fact that the UI for removing an app from
	  your session depends on whether it was autostarted or
	  SM-registered, or the fact that you can't have two copies of
	  the same program running in a session [bug 341286].)

	* To reduce the number of special case hacks the session
	  manager contains for various bits of GNOME functionality,
	  we'll add a way for autostarted programs to make changes to
	  the session manager's environment; eg, setting GTK_MODULES
	  for a11y, setting G_DEBUG for unstable-series testing,
	  setting GNOME_KEYRING_SOCKET for the keyring manager,
	  etc--currently these are all done as special cases in
	  gnome-session. The clients would work like ssh-agent (print
	  out a few VARIABLE=value lines at startup and then fork or
	  exit), and there would be a new autostart .desktop property
	  indicating that the client behaves this way. The session
	  manager would start them, read their stdout, run the
	  appropriate putenv()s, and continue starting things up.

	  We could make the splash screen a separate program too.
	  (Would this actually be useful?) The session manager has
	  .desktop files for everything it's starting, so it could
	  just do startup notification when it launches them, and then
	  the splash screen program could watch that to see what
	  icons/localized app names to put up. (We'd also need to have
	  the session manager signal somehow when the splash screen
	  should go away.)

	  Likewise, the login/logout sounds could be done by an
	  external program, with the login sound part being the
	  RestartCommand and the logout sound being the
	  ShutdownCommand. ShutdownCommands could also be used for
	  some of the other custom cleanup that gnome-session
	  currently does (eg, shutting down vino and the keyring
	  daemon).

	* The session management UI will be more icon-y and less
          command-line-y than it is now. (The session manager will
          hopefully have a .desktop file for each app, so it can use
          those to get icons and localized names.) It will probably
          communicate with the session manager via dbus, rather than
          using kludgey hacks on top of XSMP.

	* The confusing "always restore my desktop to its state from
	  March 7, 2005[2]" functionality will go away but be
	  replaced by two easier-to-understand equivalents:

		* The "Save current state" checkbox at logout will now
		  say something like "Restart the currently-running
		  applications the next time I log in". This would
		  save state for a *single* logout/login, rather than
		  saving your current state for all time until you
		  save a new state. And perhaps the button remembers
		  its state between sessions?

		* In the session management UI, you can tell it to
		  take a currently-running app, and add it to the
		  autostarted apps list, and it will save its state
		  (ie, Local SaveYourself) and cause it to be started
		  the same way later. This is for things like "I want
		  my 17 gnome-terminals to launch in the correct
		  locations."


Of course we'll want to throw away the gnome-session codebase
completely. (If you disagree, please go read the code.) The best bet
would probably be to rewrite it in C#. I'm kidding. I'M KIDDING! The
"msm" module that Havoc started several years ago and Ray Strode
continued hacking on a bit later is probably a good starting point for
a new session manager.

We also want a better client API than GnomeClient. GnomeClient is a
very very thin layer around XSMP, mostly because when it was written
there wasn't enough agreement about what certain parts of XSMP meant,
so it was impossible to abstract/simplify the API. As mentioned
before, this is somewhat fixed now[3], so we can make a nicer API
based on our new understanding. At the very least we want separate
"save_state" (Local SaveYourself) and "save_files" (Global
SaveYourself) signals, rather than a generic "save_yourself" signal
with 36 possible combinations of flags where almost every single app
in jhbuild that uses GnomeClient implements only one behavior that it
uses regardless of the flags passed (and often that behavior is not
100% correct for any of the 36 possibilities).

(And if we're moving the session management client to gtk, it should
support the equivalent Windows/Mac OS X session management
functionality as well. I think this is mostly just logout
notification/cancellation, plus the ability to add/remove programs
from the autostart list, but I haven't really investigated.)


So I'm volunteering to do all of this:

        * Write up a more detailed proposal than the above

	* Propose extensions to fdo autostart spec, and a spec
          covering the XSMP extensions and clarifications. (Hopefully
          the XSMP stuff could also go into the autostart spec.)

	* Finish/rewrite msm, add a migration path from gnome-session,
          propose for 2.18 (or maybe 2.20)

	* Reimplement GnomeClient as GtkClient, propose for gtk
          2.something.

Does this make sense or does someone want to put forth a stronger
argument for killing XSMP?

-- Dan

[1] http://code.google.com/soc/kde/appinfo.html?csaid=F40E76143F822382
    http://websvn.kde.org/branches/work/soc_ksm/

[2] http://mpt.net.nz/archive/2005/04/11/ubuntu

[3] http://www.redhat.com/archives/xdg-list/2002-July/msg00095.html