Re: session management subtlety

[Tom Tromey <tromey redhat com>]

>>>>> "Havoc" == Havoc Pennington <hp redhat com> writes:

Pardon my butting in here; hopefully my memory of these issues is
clear enough that I'm not just confusing things...

Havoc> Granted the SM spec is vague on what "global" vs. "local"
Havoc> means, but this is not my understanding of it. I think apps are
Havoc> supposed to save session state in all cases; global/local is
Havoc> IMO a useless flag (only global = TRUE is useful, local is too
Havoc> likely to lose data), but as far as I can tell, it toggles how
Havoc> apps save files, but doesn't change whether they save session
Havoc> state such as open windows.

The XSMP spec leaves much to be desired.  The muddiness of its
definition of local/global saves is one such area.  Here's a quote
from the manual
(http://www.rzg.mpg.de/from_external/sx4a_doc/g1ae04e/chap12.html):

    If save_type is SmSaveLocal, the client must update the properties
    to reflect its current slate. Specifically, it should save enough
    information to restore the slate as seen by the user of this
    client. It should not affect the state as seen by other users. If
    save_type is SmSaveGlobal the user wants the client to commit all
    of its data to permanent, globally accessible storage.

My reading of this is that `local' is used to implement something like
Emacs-style auto-save.  My reasoning is that in order to restore the
state as seen by the user, an application really has to save the data.
The cursor location doesn't have meaning without the context of the
actual file (as it is at the time of the save).  This means writing
the files and such to some temporary area.  A `global' save on the
other hand means really saving everything.

For a `both' save, I'd imagine an application would save files "for
real" and then store info about windows, open documents, etc, in
(e.g.) GConf in a per-save area.

I could understand it though if people thought that this was too
painful of an interpretation.  There are plenty of problems with it,
for instance it could mean generating lots of temporary files.  Also
it doesn't interact well with applications that already intelligently
auto-save, like Emacs (each such local save request would require
making a new auto-save file).

Havoc> Good point. However, it's still the case that the 4pm state was
Havoc> saved, and the user expects the 3 pm state to have been saved,
Havoc> right?

The session manager is responsible for keeping track of which sets of
states are in use or usable.  It garbage collects the old ones by
running the appropriate SmDiscardCommand.  Since the session manager
owns the sessions, this implies that a client must generate a new name
in response to each save request -- the client has no way of
predicting which session might actually be restored and which might be
deleted.

This is another component to implementing session-manager based
auto-save.  The idea is the SM requests periodic local saves.  When it
does a global save, or when it decides that an old auto-save file
isn't needed, it runs the appropriate `SmDiscardCommand's to delete
the old auto-save session.

Havoc> The problem with this is that it does not allow us to notify
Havoc> apps of the logout - so they can pop up "do you want to save?"
Havoc> dialogs - without also having apps save their updated
Havoc> state. i.e. it does not allow logout without saving current
Havoc> application state, does it?

As I recall, there is *no* way to request a logout without a save.  My
understanding is that you can't send a `die' command to an application
without first sending a `save-yourself' -- and the latter has no way
to say "don't save anything".  Some things are only discovered after a
very close reading of the specification.  I seem to remember that this
is implied but never actually stated in so many words.

The best you can do, assuming I have my facts straight, is have the
applications save and then immediately run all the
`SmDiscardCommand's.  Eww.  

Tom