Re: Allow page to designate itself as presentation session

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>
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).
>
> Mark.
>
> On Fri, Nov 14, 2014 at 3:03 AM, Francois Daoust <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.
>>
>>
>