RE: Allow page to designate itself as presentation session

Hi Francois, Anton, all,

From: Anton Vayvod [mailto:avayvod@google.com]
Sent: Mittwoch, 12. November 2014 21:41
To: Francois Daoust
Cc: public-secondscreen@w3.org; public-webscreens@w3.org; Bassbouss, Louay
Subject: Re: Allow page to designate itself as presentation session

Hi Francois,

I think allowing to join the remote presentations started by means other than the Presentation API should be allowed by the spec.
This is somewhat similar to how YouTube/Netflix works already on PS3, Roku and XBox 360: user has to launch the app via the remote/gamepad first and then it can be discovered and controlled by the YouTube/Netflix Android/iOS app using DIAL.

[Louay]
Thx Francois for posting this topic on the ML. This feature is also important for Hybrid TV Applications (Broadband+Broadcast) where the App Launch on the TV is triggered through the Broadcast Signal.  Also this feature is relevant for Multiplayer Gaming Applications:
- Bob Starts Poker App on his Smartphone (player.html) and Clicks on the “New Game” button to  create new Poker table on the TV using startSession(“table.html”).
- table.html advertises the session.
- Alice Starts Poker App on her Smartphone (player.html) and Clicks on the “Join Game” button to join the game session using joinSession(“table.html”) (without sessionId as second parameter). Browser on Alice’s device shows screen selection dialog only for advertised sessions on page table.html

I'm not sure how the page that's willing to be a presentation should advertise that via the spec. Any ideas? Some meta tag/manifest value?

[Louay]
Maybe using something like presentation.session.startAdvertising() and  presentation.session.stopAdvertising() on the presenting page. This will give the application control over the  advertising process. For joining an advertised session we can use navigator.presentation. joinSession(“table.html”) without sessionId as second parameter as described in the poker game example.
Do you think this feature makes sense for the 1 UA case?

Thanks,
Anton.

On Wed, Nov 12, 2014 at 5:16 PM, Francois Daoust <fd@w3.org<mailto:fd@w3.org>> wrote:
Hi all,

Louay and I chatted a bit about the following possibility a couple of weeks ago and I don't remember having seen it mentioned on the mailing-list, so here it goes.

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."

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").

What do you think?

Francois.