W3C home > Mailing lists > Public > public-secondscreen@w3.org > November 2014

Re: Allow page to designate itself as presentation session

From: Rottsches, Dominik <dominik.rottsches@intel.com>
Date: Thu, 20 Nov 2014 11:40:39 +0000
To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
CC: Francois Daoust <fd@w3.org>, "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>, Anton Vayvod <avayvod@google.com>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>, "public-webscreens@w3.org" <public-webscreens@w3.org>
Message-ID: <FC8579A0-57F3-4039-A5D3-179D8A243661@intel.com>
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.

What do you think?



Received on Thursday, 20 November 2014 11:41:11 UTC

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