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

Re: [presentation-api] Specify behavior when multiple controlling pages are connected to the session

From: Mark Foltz via GitHub <sysbot+gh@w3.org>
Date: Sun, 07 Jun 2015 23:35:12 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-109814045-1433720111-sysbot+gh@w3.org>
@avayvod Regarding the API proposal:

During the F2F we proposed the following API, in part to ensure that 
the common use case is simple, and to follow the example of 
ServiceWorker getRegistration/getRegistrations [1].  Something like 
the following:

interface NavigatorPresentation : EventTarget {
  // Returns the PresentationSession that was created when the 
presentation was started.
  Promise<PresentationSession> getSession();
  // Returns all PresentationSessions that have been connected to this
  Promise<PresentationSession[]> getSessions();
  // Fired when a new controller has connected to this presentation.
  EventHandler onsessionavailable;

In your example I had the following questions:

- What happens if the page calls `requestController` repeatedly?  It 
seems like when the Promises are all resolved then the client has to 
deduplicate the values.  The advantage of the proposal above is that 
each Promise should return the same value according to the current set
 of PresentationSessions.
- What is the initial state of the PresentationSession when a Promise 
returned by `requestController` resolves?  In the example it seems 
like the initial state value is not examined?
- What does it mean for "a page not ready to become a presentation 
yet"?  Does that mean it has not yet called `requestController`? 
- In your point #3, it sounds like the presentation can put itself 
into a mode where it rejects additional controllers, and this is 
controlled by the number of outstanding Promises for 
`requestController`.  Perhaps this could be an explicit boolean 
property like `acceptsSessions`?

GitHub Notif of comment by mfoltzgoogle
Received on Sunday, 7 June 2015 23:35:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:18:56 UTC