- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Mon, 17 Nov 2014 15:17:30 +0000
- To: Francois Daoust <fd@w3.org>, "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>, Anton Vayvod <avayvod@google.com>
- CC: "public-secondscreen@w3.org" <public-secondscreen@w3.org>, "public-webscreens@w3.org" <public-webscreens@w3.org>
Hi All, > On 12 Nov 2014, at 19:16, Francois Daoust <fd@w3.org> wrote: [...] > In essence, once we add the possibility to join an existing session or resume a connection to a running presentation session through a call to "joinSession", it seems natural to add some way for a page to advertise itself as a running presentation session, to avoid having to call "startSession" altogether. > > A typical use case: > "A user starts an application on her Smart TV that displays family pictures and videos in the background. While the application runs, her child opens the application on his tablet, joins the running presentation application on the Smart TV and adds pictures and comments to the slideshow." It appears a similar use cases have been discussed earlier, for example the multiplayer gaming on a TV suggested by Jonas [1]. Are we able to enumerate the generic requirements for this type of use cases? > The Presentation API enables the above scenario... provided the user starts the Smart TV application from another device in the first place. Said differently, the Presentation API enables more complex scenarios (Smart TV + controlling device) to create sessions, which is good, but not the more simple one (Smart TV only), which seems a bit awkward. > > 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? Thanks, -Anssi [1] http://lists.w3.org/Archives/Public/public-webscreens/2014Sep/0044.html [2] http://lists.w3.org/Archives/Public/public-secondscreen/2014Nov/0016.html
Received on Monday, 17 November 2014 15:20:47 UTC