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

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

From: Jonas Sicking via GitHub <sysbot+gh@w3.org>
Date: Tue, 01 Sep 2015 22:50:37 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-136884913-1441147836-sysbot+gh@w3.org>
I don't think that we should worry about intentionally misbehaving 

The most common case is likely going to be a website opening itself on
 the TV. In that scenario neither side is really more "user 

I think this also holds true even if website A opens website B on the 
TV. It's not obvious to me why we should consider website A as more 

So I don't think any of the options here give the user more or less 
control. But I also don't think that's a problem. The TV/dongle will 
most likely have a remote control which enables turning off whatever 
application is running on the TV.

In theory the browser could also contain some browser-provided UI for 
turning off the TV application. But I suspect that an ill-willing 
application running on the TV is a rare enough problem that browser 
won't want to sacrifice screen realestate to address that?

So I think that what we should optimize for here is developer 
ergonomics and reducing the risk of bugs.

I'm fine with @mfoltzgoogle proposal. I.e. to make the default 
behavior to leave the presentation running and then leave it up to the
 presentation code to close the application as appropriate.

I don't think we'd need a `.connected` property though. It doesn't 
seem like it'll simplify webpage logic in any significant way, and 
it's about as much complexity to implement as a 
`lastsessionterminated` event. Compare the code above to:

// 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.state == 'terminated') {
    // opensessions would be a page-maintained Set
    if (opensessions.size == 0) {
      // The last controller disconnected.  Close ourselves.  We could
     // set a timer to await new connections.

It's just two lines of code more, plus keeping a Set of open 
connections. But that's likely something that you'd want to do anyway 
in order to do operations on connected controllers.

Ultimately I think the main question here is what default behavior we 
want to have. I really don't think that either @mfoltzgoogle proposal 
or mine is hard to implement.

I don't have strong opinions on having a `.terminate()` function or 
not. As mentioned above, I don't think it provides more user control, 
but it is likely also easy to implement. It does add more requirements
 on the protocol though, so it might require a more complex protocol 
once we get around to defining that.

GitHub Notif of comment by sicking
Received on Tuesday, 1 September 2015 22:50:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 September 2015 22:50:40 UTC