Re: Gnome Session Services Framework

[Mark McLoughlin <markmc redhat com>]

Hi,
	So, I've been thinking about what we're trying to achieve here and
whether the current proposal really meets our goals, so I thought we'd
try and just write down exactly what the goals are.

	Here's a first attempt ...

Cheers,
Mark.

Goals:
======

  1. Separate notion of session services from session managed
     applications

  2. Get to a usable desktop quickly

  3. Provide good error detection and recovery

  4. Allow third parties to register session services

  5. Allow for user preferences which control whether session services
     are started

  6. Provide for application developers who need to be able to debug
     these services
 
  7. Allow for switching window managers

  8. Allow the window manager to save window positions when the user
     saves the current session state


1. Session Services vs. Session Managed Apps
--------------------------------------------

  The idea here is that the concept of "saving session state" has no
relevance to most of the programs which are currently controlled by
the session manager using XSMP. Most of the programs are parts of the
core desktop which have no "session state"; the state of these
programs are controlled entirely by user preferences.

  The proposal is to coin a new term for these programs - "session
services" - which sets them apart from applications which do have
session state.

  A simple way to think of this split would be to imagine if you could
save a session in GNOME, log in to KDE and have your session
restored. What state would you expect to be restored when you log in
to KDE? e.g. you'd expect to the browser window to be re-opened with
the web-pages you were looking at, but you'd expect the KDE panel to
be run instead of the GNOME panel.


2. Get to a Usable Desktop Quickly
----------------------------------

  At login time, the priority should be to get the core parts of the
desktop up and running as quickly as possible. Essentially, we want
the window manager, panel and nautilus running and usable as a first
priority.

  There's some non-obvious essential services, though:

    - gnome-settings-daemon needs to be launched early so that
      e.g. the gtk+ and icon theme xsettings are set

    - if we want to play a sound at login, we'd need to launch esd

    - apps contact gnome-keyring-daemon using a socket whose address
      is specified in an environment variable[1], and so the daemon
      gets launched very early so the env variable is set for all apps

  gnome-settings-daemon will need to be the first service which should
be launched. Another option would be to make it a shared library which
would be explicitly loaded by gnome-session.

  It would be nice if we could dump esd and make gnome-keyring-daemon
be launched by libgnome-keyring.

  The implication here is that launching other session services or
apps which are part of a saved session can happen once these essential
services have been launched.


3. Provide Good Error Detection and Recovery
--------------------------------------------

  We should do everything possible to ensure user ends up with a
usable desktop and is presented with useful information about any
errors which can't be resolved without the user's intervention.

  We should be able to ensure there we always launch a window manager,
panel and nautilus. If any of these fails, we could perhaps have some
way of launching it again with the default system
configuration or falling back to another program.

  We should also design the framework in such a way that there is less
of a likelihood of things going wrong. Keeping things simple will
reduce the possibility that one piece of the puzzle failing will
cause your desktop to be unusable.


4. Allow Third Parties to Register Session Services
---------------------------------------------------

  There are various projects that require a daemon to be started as
part of the login (NetworkManager, beagle, vino, gnome-power-manager
etc.). These projects should be allowed to register themselves with
the session manager rather than having to be be hardcoded in the
session manager code or configuration.

5. Allow Preferences to Control Whether Services Are Started
------------------------------------------------------------

  You could imagine a kiosk configuration with no panel or a user not
wishing to have nautilus display anything on the desktop
background. In these cases, we shouldn't be launching the panel or
nautilus at login.

  More commonly, though, if the screensaver or remote desktop access
is disabled, then gnome-screensaver or vino need not be started at
login.


6. Provide for Debugging Services
---------------------------------

  A developer hacking on something like nautilus or the panel needs
some way to replace the service launched by the session manager with
one launched from the command line. If that instance dies, the session
manager shouldn't restart it. At some point later, you want to ask the
session manager to start managing the service again.

  With the panel, currently, I do:

    - Remove the panel from the session:

        $> gnome-session-remove gnome-panel

    - Run the panel, but make sure it doesn't connect to the session
      manager:

        $> GNOME_PANEL_DEBUG=1 gnome-panel

    - When I want to go back to a normal session managed panel, I just
      run the panel without GNOME_PANEL_DEBUG and hit Ctrl-C. The
      session manager re-spawns the thing then.

  You can do the same thing with Nautilus. Metacity rocks because you
can just run metacity --replace. gnome-settings-daemon is a pain in
the ass to debug. Vino is a pain too.

  We should be able to figure out something to make peoples lives
easier here.


7. Allow Switching Window Managers
----------------------------------

  If we didn't allow people to switch window managers, we'd be
accused of some grand conspiracy or something, so we need to figure
out how someone could choose for e.g. sawfish to be the "window
manager service" rather than metacity.

  (You could argue this would be useful for the panel and nautilus too
if someone was working on a replacement for either)


8. Allow the WM to Save Session State
-------------------------------------

  When a user saves the session, the window manager saves the current
positions, size, stacking order etc. of all open windows. If the
window manager is no longer "session managed" itself, we need to
figure out how to allow it to continue to perform this task.


Other Considerations
====================

  - Should we have a way for admins/users to add non-managed, one-shot
    "run this at login" programs?

  - At logout, should the priority be to shut down quickly as
    possible? Or should we ensure all services are shut down cleanly?

  - Should we allow for profile or visualize what's happening during
    session startup? Is there anything really useful we can do
    generically here or should we assume people will just want to use
    their own tools like strace, dtrace, bootchart etc.?


[1] - We probably need to fix this to do it differently because
      e.g. programs started with D-BUS activation won't have this
      environment variable