- From: Mark Foltz via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Oct 2015 21:17:21 +0000
- To: public-secondscreen@w3.org
The Promise-based API is to avoid race conditions when the page
attempts to use the first connection before it's ready, or adds an
event handler after the first connection is ready. In some sense
there is a "stream" or queue of incoming connections provided
asynchronously to the page, and it's crucial that the presentation be
able to easily consume the first as well as subsequent elements.
The desire to have a simple API for the common case of a single
controller motivated the addition of the `getConnection()` function -
I believe @anssiko advocated for this feature.
I actually like the following proposal, which is more parallel to how
screen availability is handled (promise for initial state +
event/attribute for updates):
```
interface PresentationReceiver {
Promise<PresentationConnection> waitForConnection();
readonly attribute sequence<PresentationConnection> connections;
attribute EventHandler onconnectionavailable;
};
```
The simple case is handled by calling `waitForConnection` which will
resolve on the initial (starting) controller connecting.
Multi-controller applications can add an event handler for
`connectionavailable` in the resolver to be notified of subsequent
connections, but this is optional.
--
GitHub Notif of comment by mfoltzgoogle
See
https://github.com/w3c/presentation-api/issues/201#issuecomment-146004413
Received on Tuesday, 6 October 2015 21:17:24 UTC