Re: The future of session management in GNOME

Ray Strode wrote:

        * 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.
So at this point I'm sort of of the opinion that logout cancellation
isn't really useful.
Then you'd need to decide whether application state and overwrite all open documents, or throw everything away or somehow allow the user to individually decide (by cancelling logout!) An alternative would be to save a snapshot of current state and current open documents into a versioning filesystem and offer the user a choice of which state to restore upon login. Until versioning filesystems become more common, this would be complicated and I'm not sure there is a clear way to present the snapshot restore options on login. Maybe something like OSX's time machine.

I've been thinking about a few other things which may fit into "the future of session management." Why do we ever log out? 1) For security (A good screensaver will give you this.) 2) To switch users (Sun Ray does this, but couldn't gdm also eventually provide fast user switching without logout?) 3) Reset application environment states (Improvements to the session management GUI could reduce the need for logout here)
   4) Free up resources.   ???

Reason 4 is especially interesting for multiuser systems, especially thin clients. It might be interesting for embedded uses of GNOME (laptop/child, maemo...) to reduce resources when user isn't looking. Currently, when I pull my card out, it appears that I'm "logged out", but the GNOME applications, applets, anything with dynamic content is refreshing, polling, consuming CPU, memory and network bandwidth even though the session is no longer attached to a keyboard and monitor.
Would it be possible to:
Have session manager tell (galago?) "I'm not here" when user selects "logout/switch user" or a session card is removed. Have embedded and other devs detect "I'm not here" from keyboard timeout, suspend switch, closed lid... Use this presence information to tell applications/applets with dynamic content and UI polling to hibernate for a while. Make sure screen saver and session manager (and a user selectable set of applications) are immune to this "hibernate" signal.

It's just an idea. Just let me know if it's cracked or if it sparks off a better idea. I like the fact that I never have to log out and it takes 0.5 seconds to get back to work in the morning. And I love the fact that I can take my session home with me and continue work there in 0.5 seconds. Is the "eternal portable gnome session" paradigm workable?
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

Does this make sense or does someone want to put forth a stronger
argument for killing XSMP?
I don't have a strong argument against it, but I don't see what it
really buys us. Apps either don't support it, or support it very
minimally.  I wouldn't say it's that well understood, either.  It's
pretty ambiguous in places.

Having said that, I would love to see some improvements on this front,
and I'm sure you'll come up with something reasonable.
What (I think) XSMP does buy us is some session restore compatibility with applications from KDE, CDE and other desktops.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]