Re: [presentation-api] PresentationReceiver: rename getConnection() and getConnections()

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