- From: Mark Foltz via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Feb 2016 00:24:11 +0000
- To: public-secondscreen@w3.org
Thank you for taking this on @tidoust - the text is much simplified by removing those tuples! I think the main thing to sort out is whether there can be multiple controlling contexts in the same browser connected to one presentation. My assumption thus far has been "yes," and if that is the case, we need the (url, id) to be able to match multiple connections in the set of controlling presentations. There should be only one connection with a given (url, id) per controlling browsing context, however. With that assumption, the connect algorithm could be tweaked to either return an existing `connected` connection for that context, or create and return a new connection with the same (url, id) in a `connecting` state. In reading this, I realized that the "establish a connection" algorithm should probably have a stronger terminating condition, so that the connection returned by connect() would be guaranteed to go from `connecting` to `connected` or `closed`. For example: if the user clicks a button to reconnect, the reconnecting page would show the user a spinner while connecting, and would want to eventually show an icon showing connection or error. We can probably tweak the example code to make this use of the API clearer. I had a couple of naming suggestions, which you can take under consideration. -- GitHub Notification of comment by mfoltzgoogle Please view or discuss this issue at https://github.com/w3c/presentation-api/pull/252#issuecomment-178271219 using your GitHub account
Received on Tuesday, 2 February 2016 00:24:15 UTC