Re: Session Management Proposal

[Ray Strode <halfline hawaii rr com>]

[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