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: Thu, 03 Sep 2015 23:24:30 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-137600281-1441322669-sysbot+gh@w3.org>
I'm relaying some internal discussion for the benefit of the group 
(paraphrased).  The following arguments were put forth in favor of 
adding an explicit API that would allow any controller to request 
ending the presentation (versus `.close()`, which disconnects an 
individual controller).

1. It would simplify the life of Web developers who expect a way to 
terminate a presentation directly through the API, instead of 
implementing some application level mechanism.  In particular the Cast
 SDK exposes this functionality [1].

2. It provides the user an additional control over the state of the 
display and makes it more likely that the state of the controller and 
the presentation are in sync.  I.e. if the presentation should always 
go away when the controller does, the controller can put 
`session.close()` in `window.onbeforeunload` or the equivalent.

3. The user may have two different intents, and the API should have a 
way to express each of them.
  - Disconnect my controller from the presentation, but leave it 
running (if it wants to)
  - Terminate the presentation

4. Every display protocol (whether 1-UA or 2-UA) almost certainly have
 a way to terminate the presentation.  Instead of having two ways to 
terminate, one from the controller's browser, and another via 
application messaging or connection status, it seems cleaner to share 
the implementation via the API.

Overall I'm fairly persuaded by these arguments.

@sicking I'll reply about `lastsessionterminated` when I have a bit 
more time, and draft an API change that summarizes my current 

GitHub Notif of comment by mfoltzgoogle
Received on Thursday, 3 September 2015 23:24:32 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 September 2015 23:24:32 UTC