Session Management Proposal

[Oswald Buddenhagen]

On Wed, Dec 31, 2003 at 11:34:34AM -1000, Ray Strode wrote:
> Oswald Buddenhagen wrote:
> > 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.
> 
oh, there are already predefined constants ... uhm ... this has
potential to break existing apps, then. better not ...

> 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.
>
there is ... usually with InteractModeDefault, enforcable with
InteractModeActive. iow, this popup box is what InteractMode is all
about ...

> 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.
> 
no, see above. i'd prefer to "abuse" the fast flag as a three-state
variable, provided libSM does not cut it to one bit somewhere. i think
it's save to assume that apps will actually pass 1, not anything else 
non-0 as TRUE, so -1 (for example) could be interpreted as "slow".

> 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.
> 
yup

> > 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.
> 
eeek ...
i think i'd put everything into one ARRAY8, simply defining a struct -
this could contain ShutdownMode (hmm, i called this ShutdownType in kde)
as well, so everything "post-exit"-related is covered in one property.
btw, do we have to care for endianess at all? i.e., can XSMP wire data
be actually passed across hosts?

> > 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.
> 
no ... the requests to the dm are always scheduled for after the session
exits by itself (i implied it, george said it explicitly). not putting
this stuff into the sm has only two disadvantages: a) more code in the
client and b) the client would have to cancel the system shutdown
request to the dm again if the session shutdown request to the sm failed.
given that in kde this is encapsulated in KApplication::requestShutdown
anyway ...
it's still more convenient to have it, but there are no strong reasons.

greetings

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.