Ray Strode wrote:
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.* 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.
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?
What (I think) XSMP does buy us is some session restore compatibility with applications from KDE, CDE and other desktops.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.awesome.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.