Re: [presentation-api] Refine how to do session teardown/disconnect/closing

I'd think user would prefer being in control - imagine a presentation 
that
misbehaves intentionally or not and doesn't shut itself down. There 
must be
a way to explicitly stop the presentation that doesn't involve 
rebooting
the second screen.
On 1 Sep 2015 4:23 a.m., "Mark Foltz" <notifications@github.com> 
wrote:

> I actually think we can come to a good solution here by adjusting 
the
> semantics I proposed earlier, and without any API facing changes. 
Let's
> assume we redefine close() to mean disconnect() as discussed above.
>
> Below "controlling session" means a PresentationSession in the 
controlling
> page and "presentation session" means one in the presented page.
>
>    1. Controlling page calls session.close():
>       - Controlling session transitions to terminated
>       - Corresponding presentation session also transitions to 
terminated
>    2. Presentation is closed (by itself, by user agent, by user)
>       - All controlling sessions transition to terminated
>    3. Controlling session is disconnected from presentation without 
any
>    call to close() (e.g. user changes WiFi networks away from TV,
>    navigates away, etc.)
>       - Controlling session (if it exists) transitions to closed
>       - Corresponding presentation session on the presentation also
>       transitions to closed
>       - Presentation continues to run
>       - Controlling page may want to offer "reconnect" as an option 
to
>       the user to resume connection via join().
>    4. Presentation wishes to "kick out" a controller (idle timeout, 
etc.)
>       - Calls session.close() which causes the corresponding 
controlling
>       session to transition to terminated.
>    5. Last connected session to the presentation transitions to 
closed or
>    terminated .
>       - Presentation will see that all sessions are in the 
non-connected
>       state. It can close itself with window.close() it if wants to,
 or
>       wait for new connections.
>
> To simplify case 5, we can add a boolean connected property to the 
change
> event fired at a session's onstatechange. The property would be true
 if
> there are any sessions held by that browsing context that remain 
connected
> to the presentation, false otherwise.
>
> Here is a bit of sample code for the presenting page under this 
proposal:
>
> // Assume that the page already is adding the following handler to
> // incoming connected sessions.
> session.onstatechange = function(e) {
>   if (e.state == 'closed' || e.state == 'terminated') {
>     // Show a message that a player/controller left the 
presentation.
>   }
>   if (!e.connected) {
>     // The last controller disconnected.  Close ourselves.  We could
 also
>     // set a timer to await new connections.
>    window.close();
>  }
>
> This proposal does not give a single controlling session the ability
 to
> terminate the entire presentation. This may actually be desirable; a
 single
> player should not be able to kill the whole game, and as @sicking
> <https://github.com/sicking> argues above the presentation may be in
 a
> better position to know when to quit.
>
> I still prefer using window.close() as an explicit mechanism for
> terminating the presentation page, rather than relying on a new 
event's
> default behavior. If there is a good reason to create the 
default-close
> behavior, is there a way to do it without adding a new event?
>
> —
> Reply to this email directly or view it on GitHub
> 
<https://github.com/w3c/presentation-api/issues/35#issuecomment-136564607>
> .
>


-- 
GitHub Notif of comment by avayvod
See 
https://github.com/w3c/presentation-api/issues/35#issuecomment-136642042

Received on Tuesday, 1 September 2015 09:06:30 UTC