Session Management Proposal

[Ray Strode]

Oswald Buddenhagen wrote:

> > Okay, so you interpret the fast argument to mean "fast shutdown"
> > instead of "fast save" (i.e. shutdown = False, fast = True is
> > meaningless). That sounds fine to me.
> >
>  yup. matthias was not sure if he got it right - maybe he wants to
>  comment on this? :)=

Well it seems pretty reasonable to me.
shutdown = False, fast = True doesn't seem to be very useful anyway.

> >> "slow" would be just the opposite, i.e. "shutdown with
> >> confirmation", regardless of the user's setting. independently
> >> from any other client, only a part of the client doing the
> >> request. that _could_ be useful for clients that want to initiate
> >> a shutdown without prior explicit user action. i have no idea,
> >> whether this could be actually useful for anything.
> >
> > I'm not sure I completely understand this part. By "slow" do you
> > mean fast = False or are you talking about adding something new to
> > the spec?
> >
>  about adding something new - i thought that would be clear from the
>  context. the other case would be "normal" as in "neither fast nor
>  slow", i.e., obey the user's setting (default is same as slow).

Oh, I think I may understand you now.  You are saying that some users
don't want to be bothered on logout by "Do you want to save?" dialogs
and would rather the applications just save themselves quitely.  And so
you think there should be three options:
   1) Have the "Do you want to save?" dialogs no matter what the user
      wants. (slow)
   2) Don't have the "Do you want to save?" dialogs at all no matter what
      the user wants. (fast)
   3) Only put the "Do you want to save?" dialogs up if the user wants
      them.  Otherwise don't. (normal)

Do I understand you right, now?  How do you want to implement that in the
spec? Currently, fast is a boolean, which means only two values.  This
leaves us with a few options I think:

   a) We could ignore that it's a boolean, treat it like an enumeration
      and hope smlib doesn't canonicalize its booleans. (bad idea)
   b) Add a new property "_NET_ShutdownNotFastMode" (Or whatever) that would
      specify the slow or normal case when fast = False.
   c) Ignore the fast argument to SaveYourselfRequest completely and have a
      "_NET_ShutdownInteractMode" that would cover all three possible 
values.

Which do you like best? Or do you have another idea?  I think my preference
would be c), but I wouldn't be opposed to b) either.

--Ray