W3C home > Mailing lists > Public > public-secondscreen@w3.org > October 2015

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

From: Jonas Sicking via GitHub <sysbot+gh@w3.org>
Date: Thu, 08 Oct 2015 04:44:26 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-146418674-1444279465-sysbot+gh@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 

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 
 archives that. It means that for the common case, when an app only 
ever deals with a single connection, you just write

  (connection) => doStuff(connection));

And for pages which supports multiple connections you'd do something 

var myConnections = [];
function updateConnections() {
    (connections) => {
      myConnections = connections;
navigator.presentation.receiver.onconnectionavailable = 

Yes, someone might try to support the single-connection usecase by 
  (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
Received on Thursday, 8 October 2015 04:44:30 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 October 2015 04:44:31 UTC