- From: Anton Vayvod via GitHub <sysbot+gh@w3.org>
- Date: Fri, 05 Jun 2015 15:50:01 +0000
- To: public-secondscreen@w3.org
I think the issue can be resolved with a Promise returning method on the NavigatorPresentation instead of the ```session``` property (as agreed in the solution for #19 ). If the page calls the method (e.g. getSession()) it means it now switched to the presentation mode and is willing to accept connections and environment restrictions. The UA could also present user with a permission prompt if it's an interactive UI and the page wasn't running in an incognito context / started as a response to some page trying to present to the screen. To join the presentation started from A, B only needs to know the URL, not id. Id is needed for resuming/joining a session (vs. presentation) started from the same UA. We agreed to remove id from startSession(). Selecting the right screen is on the user - if my friends and me decided to play a game together, one starts the game on the TV, others select the same device and the game presentation should be able to accept connection from game clients. A shared TV could have a browser or an interactive webapp (e.g. Spotify) that can be used without presenting (via remote control / TV's touch screen). Now I may want to allow my guests to connect to the screen to add their music to the queue using Presentation API but don't want any info saved - so while the page has connections from other clients, it shouldn't be able to save or remember anything. Perhaps we should have a method similar to opening a window for the page to become a presentation... So the interactive page calls this method and its presentation version is loaded in the incognito context and is ready to be connected to. We may want the initial page to be able to message the presentation one turning it into a special case of the Presentation API :) -- GitHub Notif of comment by avayvod See https://github.com/w3c/presentation-api/issues/32#issuecomment-109337907
Received on Friday, 5 June 2015 15:50:02 UTC