- From: Jonas Sicking via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Oct 2015 04:44:26 +0000
- To: public-secondscreen@w3.org
I'm not sure I understand the proposed behavior of `waitForNextConnection`. What qualifies as "next". I.e. if a connection is established, and 5 seconds later the page for the first time calls `waitForNextConnection`, will that wait for the second connection? Does each call to `waitForNextConnection` "consume" a connection from the queue? And so the scenario above is guaranteed to always return the first connection. What happens if you have two parts of the page which both needs access to the connection. Does that mean that the second caller of `waitForNextConnection` will wait for a second connection which is never coming? I think we should think about what we're trying to archive with this API. My goals have been: * Make it possible to get a list of connections and get notified whenever that list changes. * If possible, create a simpler syntax sugar API for the common case of only having a single connection. (Have we added the API to make multiple connections opt-in yet?) * Reduce the risk of races. I think the API in https://github.com/w3c/presentation-api/issues/201#issuecomment-146004413 archives that. It means that for the common case, when an app only ever deals with a single connection, you just write ``` navigator.presentation.receiver.waitForConnection().then( (connection) => doStuff(connection)); ``` And for pages which supports multiple connections you'd do something like: ``` var myConnections = []; function updateConnections() { navigator.presentation.receiver.connections.then( (connections) => { myConnections = connections; updateUI(); } } navigator.presentation.receiver.onconnectionavailable = updateConnections; updateConnections(); ``` Yes, someone might try to support the single-connection usecase by writing ``` navigator.presentation.receiver.connections.then( (connections) => doStuff(connections[0])); ``` But there's really very little reason to do so since the correct code both looks more correct and is just as simple. We could even cover this case too by saying that the `.connections` promise shouldn't resolve for the first time until the connection which caused the page to get started has been properly created. That should be easy to do implementation-wise. -- GitHub Notif of comment by sicking See https://github.com/w3c/presentation-api/issues/201#issuecomment-146418674
Received on Thursday, 8 October 2015 04:44:30 UTC