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

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

From: Anton Vayvod via GitHub <sysbot+gh@w3.org>
Date: Thu, 08 Oct 2015 18:31:12 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-146646834-1444329071-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 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.

I believe that's the intent, yes.

> 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?

Yes. Do you think that could be a common problem? Why wouldn't the 
page just pass the first connection it receives to its other parts?

I believe that losing the single connection would be a problem and 
most of the presentation pages would like to allow users to reconnect,
 so having waitForConnection() return the new connection sounds useful
 (the page would call it again when the first connection changes to 
terminated state, for example).

> 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.

I think the multiple connections case is far less common so I'm not 
sure why we should optimize the first iteration of the spec for that.

> 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?)

No, we haven't added such an API, so even if the page only cares about
 one connection, it can potentially get more connections but ignore 
them. The UA could then terminate the ignored connection after a 
timeout, for example. It might be harder to do though if we introduce 
the ```sequence<PresentationConnection>``` to the API in any form.

> Reduce the risk of races.

I think having just one method accomplishes that better than three 
overlapping things. Having an event and two promises for one and many 
connections seems to be more likely to introduce races (e.g. event is 
fired for a new connection, the page calls ```getConnections()``` but 
the connection is lost in the meanwhile so the page doesn't get any 
connection when the promise is resolved).

I also think that the minimalism approach to this spec is also a good 
argument in favor of just one method: we could always add better 
syntax for multiple connections support later.

GitHub Notif of comment by avayvod
Received on Thursday, 8 October 2015 18:31:14 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 October 2015 18:31:15 UTC