Re: Allow page to designate itself as presentation session

CIL


On 14 Nov 2014, at 20:21, Anton Vayvod <avayvod@google.com<mailto:avayvod@google.com>> wrote:

Agree with Mark, we seem to be sorted out on the sender side.

On Fri, Nov 14, 2014 at 5:53 PM, Mark Scott <markdavidscott@google.com<mailto:markdavidscott@google.com>> wrote:
I believe startSession already handles this scenario reasonably, perhaps with some clarification around url and presentationId and intended UX.

We already state that if both parameters match (or if presentationId is unspecified), that the user is joined to the existing session.  In your original example, the photo app launched directly on the Smart TV (e.g. via on-screen TV UI) can still have an effective url (and possibly also presentationId).  In this case, the second participant can still call startSession with a matching url, and if they choose to present to that Smart TV, they'll be joined to the session that already exists on the TV directly.

I think startSession semantics where device selection is performed makes more sense than joinSession in this case, because you will want user confirmation in basically all cases when joining from a different device.  Otherwise, you invariably leak information to a page about what sessions already exist, which makes it possible for pages to potentially track user behavior (e.g. by supplying the urls associated with common apps).

Thx Mark completely agree that startSession is more suitable than joinSession for this purpose.

Mark.

On Fri, Nov 14, 2014 at 3:03 AM, Francois Daoust <fd@w3.org<mailto:fd@w3.org>> wrote:
On 2014-11-12 21:40, Anton Vayvod wrote:
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.

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?

Attaching to navigator.presentation.session.onstatechange could be one way:
- we tweak the spec saying that the presentation.session object is null only if the UA doesn't support the remote UA mode and not-null but in the disconnected state if there's page wasn't launched as a presentation via the presentation API
- the page subscribes to the onstatechange event and the UA regards it as a running presentation with no id, now presentation API clients can call startSession with no id and the user can select this presentation


I don't know if a declarative-only approach is enough. Let's imagine a little girl playing a game on her console. She might not want her annoying little brother to be able to join the game at any time without her willing to. Now, the game app can of course handle incoming connections and ignore them if they are not wanted, but it would seem cleaner for the game app to be able to propose a menu option that says "start hosting game session" for instance to ensure it won't receive any incoming connection notification before it is willing to accept them.

Should the brother be able to present something else on the screen or will the game shut down the discovery completely? Should the game manage the discovery to limit the number of simultaneous connections (e.g. 2 for chess or mortal combat and 4 for avengers) ?

In this case we might want to add start/stop methods Louay suggests.



Francois.