- From: Anton Vayvod via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Oct 2015 18:31:12 +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. 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). WDYT? 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 See https://github.com/w3c/presentation-api/issues/201#issuecomment-146646834
Received on Thursday, 8 October 2015 18:31:14 UTC