W3C home > Mailing lists > Public > public-secondscreen@w3.org > September 2015

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

From: Mark Foltz via GitHub <sysbot+gh@w3.org>
Date: Tue, 01 Sep 2015 03:23:56 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-136564607-1441077835-sysbot+gh@w3.org>
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 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?





-- 
GitHub Notif of comment by mfoltzgoogle
See 
https://github.com/w3c/presentation-api/issues/35#issuecomment-136564607
Received on Tuesday, 1 September 2015 03:23:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 September 2015 03:23:58 UTC