- From: Mark Foltz via GitHub <sysbot+gh@w3.org>
- Date: Fri, 14 Apr 2017 17:14:38 +0000
- To: public-secondscreen@w3.org
If I'm not opposed to this change, but would need to investigate the implications for our implementation to determine the scope and complexity. It does seem to improve ergonomics for the cleanup case, but isn't the expected use case to simply allow the connection to be closed by the controlling UA on page unload? The presentation can close itself when it detects the connection has goneAway. I went ahead and thought through the implications for the API and what we signal to developers. When script calls `terminate()` on a connected presentation, there's an assumption that it will succeed by default, since the presentation is known to exist and the controlling user agent has some way of communicating with it. If we allow `terminate()` to be called in any state, then all bets are off. Although `terminate()` is more or less best effort anyway, this seems to change the nature of the API. I ask the following: - If the presentation is known to no longer exist (i.e. its state is `terminated`) should we allow terminate to be called or throw an exception? - For the `closed` state, should we make a best effort and report back success or failure if controller believes the presentation exists and the signal was able to be sent to the receiver? Perhaps: `Promise<void> terminate()` For `connecting` or `closed`, I don't think there is a need to transition to `connected` then `terminated`, since there is no need to message a presentation that is about to be torn down. The algorithm changes could be tricky given the fact that `terminate()` can be called at any time. -- GitHub Notification of comment by mfoltzgoogle Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/421#issuecomment-294194178 using your GitHub account
Received on Friday, 14 April 2017 17:14:44 UTC