RE: Allow page to designate itself as presentation session

Hi Dominik,

> -----Original Message-----
> From: Rottsches, Dominik [mailto:dominik.rottsches@intel.com]
> Sent: Donnerstag, 20. November 2014 12:41
> To: Kostiainen, Anssi
> Cc: Francois Daoust; Bassbouss, Louay; Anton Vayvod; public-
> secondscreen@w3.org; public-webscreens@w3.org
> Subject: Re: Allow page to designate itself as presentation session
> 
> Hi Louay,
> 
> >> Or perhaps this could actually already be handled at the UA level: if the
> UA detects code in a Web app that e.g. listens to presentation session
> connections, it could perhaps offer an option on the UA's user interface to
> start the session directly (with a choice that says "and do that automatically
> next time the app starts").
> >
> > Anton's response [2] seems to suggest no normative changes are needed
> to the API on the sender side. Correct?
> >
> > Do we yet have an understanding of the changes (if any) required to the
> API exposed to the receiver side?
> >
> > Also, I'd like to understand whether we could leave this up to the
> implementation (i.e. "handle at the UA level") and still expect users to figure
> it out regardless of the UI/UX differences?
> 
> In order to reduce complexity and limit scope of what we’ll have to specify, I
> think there should always be only one active 1:1 controlling relationship
> between an opener page and a remote/presentation page.
> 
> Nevertheless, the gaming use case that you’re describing in
> https://github.com/w3c/presentation-api/issues/27 can be achieved.
> Already currently, things like browser side conferencing, shared
> whiteboards, multiplayer gaming are possible through server side
> matchmaking or exchanging simple game/call IDs.
> 
> I would argue that these things are possible through XHR or WebRTC or a
> combination. Vicinity can be established through virtual matchmaking rooms,
> geolocation or - as mentioned - exchanging simple game/multiplayer room
> identifiers on a side channel. If you’re looking for more sophisticated player
> discovery, e.g. “are there potential game participants nearby?”, perhaps
> something like a web API for Bluetooth (Low Energy) could be useful.
> 
> I would argue that we do not need to specify anything in Presentation API
> specificially for the matchmaking aspect of multiplayer gaming.
> 
> So, the scenario you’re describing could be implemented as follows: One
> local player is responsible for pushing the poker table to the big screen. Once
> that player leaves the game and disconnects from the display, the
> presentation session id is transferred to another remaining player via the
> game server who then resumes the presentation session.
> 
Thx for feedback. I was thinking about using Presentation API for realizing offline multi-user applications (most relevant examples are Multiplayer games)  without the need to write code for the server side (only for serving the html files). It will make the development of these kind of applications much easier. What do you think about this flow to implementing the Poker example using presentation API?

1- Control page player.html of first player uses  startSession("table.html"), UA shows screen selection dialog,  User selects target display, table.html is launched on selected display
2- Control page player.html of second player uses  startSession("table.html"), UA shows screen selection dialog,  User selects same target display, control page connects to  running table.html 
3- player.html (of first and second player) uses postMessage()  and onmessage to exchange data with table.html
4- table.html uses postMessage to broadcast data to all senders  and onmessage to receive data from any player

For these steps no changes on the current spec are needed. But I think It is better to allow the presenting page to send data to a specific sender like this:

// player.html
session.postMessage("join game");
// table.html
session.onmessage = function(msg, sender){
       if(msg == "join game" ){
               // reply to sender
               session.postMessage("joined", sender);
       }
}

@Anton, @MarkF: Google announced to introduce fun family games for Chromecast [1]. Can you give us Feedback on how additional players can join a running game? 

 Regards,
Louay 

[1]: http://chrome.blogspot.ca/2014/11/introducing-fun-family-games-for.html?m=1

Received on Friday, 21 November 2014 11:54:43 UTC