Session Management Proposal

[Ray Strode]

Oswald Buddenhagen wrote:

>  yup, the last paragraph reads "If a client initiates a
>  SaveYourselfRequest with shutdown set to True but does not set the
>  _DSME_ShutdownInteractMode property first, then the session manager
>  should assume an implied mode of _DSME_ShutdownInteractModeActive if
>  the client initiating the request set fast to False and the session
>  manager should assume an implied mode of
>  _DSME_ShutdownInteractModePassive if the client initiating the
>  request set fast to True.".
>  s/_DSME_ShutdownInteractModeActive/_DSME_ShutdownInteractModeDefault/,
>  as otherwise every DSME-unaware client would override the user's
>  setting.
Oh yup, thanks.

>  one thing i'm not sure about is the "interact-style". without reading
>  the xsmp spec it sounds like this is what matthias interpreted
>  "fast" as. but then one would wonder what "fast" is. bah, i have to
>  read the damn spec some day. :)
Yea I think the bottom line is there are a bunch of not well defined
arguments and we just need to pick which ones were going to use, and
pick which ones we're going to ignore.  "interact-style" is sort of
interesting because it is defined to have three values so it could
almost be used instead of "_NET_ShutdownInteractMode".  We could
define "None" <-> "Passive", "Errors" <-> "Default",
"Any" <-> "Active".  The only ugliness there is the
"Errors" <-> "Default" mapping.  I don't mind if we keep it the way
it is now or change it.  Whatever you think.

Something that just popped into my head, (and you may have been
trying to tell me this earlier and I missed it), is that right now
clients who want to shutdown send a SaveYourselfRequest with
shutdown = True and then the session manager responds by popping
up a little box asking what type of shutdown the user wants.  With
the current spec, there is no way for this to happen anymore.
Possible shutdown modes are: 
      1) Log Out
      2) Shutdown
      3) Reboot
      4) Pick one of the above choices from a setting or remembered
         value.

My reasoning for the first 3 was so that shutdown could be added as
separate options in panel menus, and I sort of lost sight of the
fact that theree still needs to be the dialog shutdown method, too. 

Okay, so here's my new proposal:

When a client sends a SaveYourselfRequset with shutdown = True,

We use the somewhat dubious interact-style mapping talked about above
and just get rid of _NET_ShutdownInteractMode.

We use fast = True to mean "Assume the client has already asked the
user which way to shutdown, and that the user wants to shutdown in
the fashion specified by the shutdown mode".  In this case we don't
ask the user, we just immediately send the request to the desktop
manager

We use fast = False to mean "Assume the client wants to shutdown
in the fashion specified by the shutdown mode, so ask the user if
that's okay (and offer other shutdown options)". In this case
we pop up a little box with radio buttons (or push buttons or
whatever), with the selected radio button being the one specified
by the shutdown mode.

How's that sound?  This way we are getting the maximum amount of
functionality we can from the arguments available.

>  i'll think about a ShutdownTiming property, but a) it would have to
>  be two properties (CARD32 timeout, CARD8 force)
Okay, be careful here.  The XSMP and smlib don't provide for properties
to be CARD32.   Your choices are CARD8, ARRAY8, and LISTofARRAY8.  If
we determine we need 32-bit values then we are going to have to define
them to be ARRAY8 of length 4 in network byte order or something.

>  and b) i'm not sure
>  how useful that would be to xsmp clients (hmm, strictly speaking the
>  shutdown mode is just as irrelevant for normal clients, esp. if the
>  dm interface is standardized, so clients can schedule post-logout
>  actions without bothering the session manager. so after all it comes
>  down to whether adding (system) shutdown options as a convenience
>  feature of xsmp (making it a gateway to the dm) makes sense at all).
the session manager needs to know when the session is going to end, so
it can tell the clients to save their state first.  If one client
circumvents the session manager and just talks straight to the
desktop manager then there will be no way for all the other clients to
save.

--Ray