Re: Session Management Proposal



[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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]