Session Management Proposal

[Ray Strode]

[forwarding because I pressed the wrong reply button]

Hi Oswald,

>a counterpart to "fast" ("slow" - hehe) shutdown could be useful - if
>fast means no confirmation dialog, slow would mean always confirm, even
>if it was configured away - that could be useful for shutdown requests
>"out of the blue" (for whatever reason somebody might want to do that).
>
>  
>
So you are saying that:
   
   1) We should honor the fast variable from SaveYourselfRequest
      messages (which was one of the open questions in my first
      message).
   2) We should add a new client property that overrides the
      value of the "fast" argument ("_NET_NoFastSaves" or
      whatever).

Then, if a client initiates a SaveYourselfRequest method with
fast set to "True", the session manager should ensure that no
other clients have "_NET_NoFastSaves" set to "True" before
propagating the fast = True value to each of its clients.

Did I understand you right?  This is to prevent potentials
for abuse, right?  As I see it, there are two bad things things
that a bad client can do if we honor the fast argument. 
    1) The first is to send a SaveYourselfRequest with
       fast = True and shutdown = True for no legitimate
       reason.  In this case, all of the user's documents are
       automatically saved and the user is logged out. For
       instance a program could set itself to restartalways on
       login and immediately send the SaveYourselfRequest
       causing the user to be instantly logged out. 
      
       The thing about this situation is there are legitimate
       use cases for fast = True and shutdown = True.  For
       example the UPS power failing thing mentioned in the
       XSMP or a quick logout hotkey may want to be able to
       do this.

   2)  The second bad thing that can happen, is say a user
       opens up a document, starts to modify it heavily and
       then wants to save it under a different name.   A
       different - but broken - client could send a
       SaveYourselfRequest with fast = True and
       shutdown = False before the user gets the chance to
       save the document under a different name. This would
       cause the user's original document to get
       overwritten.

Now the question is, does "_NET_NoFastSaves" solve either 1)
or 2)?  No single client on the desktop can know what the
right course of action is for either of these situations.

The more I think about the UPS power failing situation, the
more I think it shouldn't be handled (at least soley) by the
session manager.  What if the system has more than one
active session?  Which session manager actually performs the
shutdown?  You address this problem later to some extent
later in your message.

>>If the initiating client did
>>+      not set the "_NET_ShutdownMode" property, then the session
>>+      manager should assume an implied shutdown mode of
>>+      "_NET_ShutdownModeLogOut".
>>
>>    
>>
>... for compatibility.
>  
>
adding for compatiblity sounds nice.  Thanks.

>but then we need a mode "Default".
>  
>
The default mode would mean the session manager gets to choose based on 
a setting
or what the user chose last or whatever?  That seems useful.

>another thing i'm wondering about is "Suspend" mode. considerations:
>- like reboot/halt it might need authorization - after all it makes the
>  box unresponsive to network activity (apart from WOL, etc.)
>- but it doesn't need to end the session
>- still, it could be useful to tell all interested applications that
>  they should enter some passive state. i'm not sure this should be done
>  over xsmp, though - maybe some generic d-bus based system would be
>  more useful
>  
>
I'm not really sure either.  One consideration is if we add 
"_NET_ShutdownModeSuspend" or
whatever, then when legacy applications see shutdown set to "True" they 
may assume that
the session is about to end and so they may act inappropriately.

>the next point is communicating the system shutdown request to the
>desktop manager, as that's the place it belongs to. currently kdm has a
>one-way command fifo and gdm has some fancy command socket. i'd like to
>replace that with something common, possibly based on d-bus - dunno.
>  
>
I agree that it would be nice if we could get the desktop managers to 
actually handle doing
the shutdown/reboots.  Typically they have permission to do it, and they 
also should be able
to know if there are other active sessions that should prevent the 
shutdown from happening.
Having said that, the session manager can't really assume that there is 
a desktop manager
I don't think, because some people don't use them.  It sounds like its 
going to be a complicated
problem to solve.

>yet another option to system shutdown ... kdm supports three "shutdown
>timings": "force now" (the usual thing), "try now" (shut down only if no
>user session is open) and "schedule" (shut down when last user session
>exits). "schedule" could be generalized to take a timeout - "try now"
>would be the special case 0 then. "force now" could be coalesced into
>the generic "schedule" mode by adding a timeout action: "cancel" and
>"force shutdown".
>as these scheduling modes are way too complicated for normal users
>(believe me, i tried it :), the usual course of action should be to pop
>up a warning box "sessions are still open. what now? [cancel] [schedule]
>[kill 'em all!]" on demand. i.e., the shutdown request needs a
>"fast/slow" "sub-option" for "fine-grained options" (the defaults would
>be to hide this feature entirely unless explicitly enabled it in the
>control center).
>
>when interactive shutdown is choosen (i.e., the default), the shutdown
>mode and timing parameters are used as presets for the dialog, not as
>the only option. well, that's self-evident, i guess.
>
>  
>
Okay, these features sound reasonable, but we are moving from the realm
of session manager to desktop manager.   I guess when its figured out how
exactly the desktop manager and the session manager are going to
interact, we can add something to the session manager document explaining
that interaction.

Thanks,
--Ray