Re: Allow page to designate itself as presentation session

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?
>>
>
> 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.
>
> Francois.
>
>