Re: session management subtlety

[Havoc Pennington <hp redhat com>]

Matthias Ettrich <ettrich trolltech com> writes:
> > Here is the problem. Say I log in at 2 pm, save my session (but don't
> > log out) at 3 pm, and then log out and do not save my session at 4 pm.
> 
> How do you save your session in KDE but don't log out? Isn't that quite 
> esoteric? The only way to achieve this is to start logging out with save 
> session checked and aborting the logout via some cancel button.

I understand that ksmserver doesn't allow the situation - that's why I
pointed out that things work as long as you stay ksmserver/KDE
apps. However, other session managers - such as gnome-session - do
allow this, and the KDE apps don't handle it. So there's an
interoperability problem.

Also, I think ksmserver probably _should_ respond to a
SaveYourselfRequest with shutdown = FALSE by doing a save without a
logout - even if KDE doesn't offer UI to send that
SaveYourselfRequest.

> In case you log out with "do not save" checked, the applications receive a 
> SaveYourself with "Global" only. In other words: they might ask the user to 
> save modified files, but they won't write anything in their session 
> configuration.

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

> > Assuming applications store their state per-session-ID, rather than
> > per-SaveYourself, the result is that I would get the session file from
> > 3pm, but the application states from 4pm. This means that e.g. I might
> > get the wrong number of windows open for an app. The worst case
> > scenario when getting the wrong number of windows is to get too few,
> > because the window manager gets confused and restores session state to
> > the next window the user opens manually. (This can result in fun stuff
> > like the window manager maximizing a dialog.)
> 
> The window manager should have received a saveYourself message as well. If it 
> stores its session data only tagged with the sessionId, it shouldn't matter 
> if the session manager uses an old session file to restart the wm.

Good point. However, it's still the case that the 4pm state was saved,
and the user expects the 3 pm state to have been saved, right?
 
> My first implementation had something similar. I wasn't using a random 
> string, but some additional counter. So there wasn't only a session id per 
> application, but also a reincarnation id within that session.  I also wanted 
> to make it possible to login into session "Work", and eventually save what 
> you have as session "Work2", with "Work" still being available. 
> 
> My feeling back then was that it got too complicated, and that programmers 
> and users had enough trouble already understanding session management 
> (especially the local mode) as it was.

I would generally agree that the full-blown SM spec is hard to
understand and get right. I think we can bury a lot of the details in
libraries though. Really all that's important is that apps open the
same windows that they had open on session save - I don't think much
other information should really be part of the session state. You
should be able to just hand apps a KConfig object and tell them to
write data to it, more or less... 

> But it really is a bug in the protocol. The easiest and cleanest solution 
> would be that a saveYourself message featured a new session id for the 
> client.

Is that required? If we have the library generate such an ID, it's
just as good from an app developer standpoint, right? i.e. there's no
reason this ID has to come from the SM.

> > Anyhow, there are two possible fixes I can see. One is to require that
> > session managers always record the latest RestartCommand of any app
> > that has received a SaveYourself. i.e. the SM must save to disk if the
> > app saves to disk. 
> 
> This sounds like the right suggestion for the time being. In order to be able 
> to implement it, I'd like to know how you achieved the situation in question 
> with ksmserver (other than a cancelled shutdown).

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

> > The other is to require that apps save state
> > per-SaveYourself, not per-session ID. In either case, I think
> > documenting the clarified behavior would be a good idea.
> 
> The third possibility might actually be to extend the protocol to send 
> clients a new session ID in the save yourself message.

Matthias Clasen points out that the XSMP spec actually does already
require the second suggestion, that state be saved per SaveYourself.

Havoc