Re: Allow page to designate itself as presentation session

Re-reading this thread - there seem to be two possible behaviors that need
to be clarified:

(1) Do we need a mechanism for a presentation to tell the user agent that
its session is "discoverable/joinable" or not.

(2) One possible way to implement #1 is for the presentation to (re)-assign
a random presentation id to its active PresentationSession, which would
prevent additional connections from being made.  (The running presentation
would be responsible for sharing this new id with existing connected
sessions if it wants them to be able to reconnect.)

Assuming this is accurate, I will update GH Issue #32 with this summary.

m.


On Mon, Dec 1, 2014 at 5:37 PM, Mark Scott <markdavidscott@google.com>
wrote:

> Francois, thanks for your clear statement of the flow - what you're
> describing here is a clear statement aligned with my earlier message.
>
> Re #4, if we make it possible for the app to define presentationId even
> when started locally, it can use a randomly generated presentationId to
> prevent others from joining.  It can ignore incoming notifications as an
> added security measure.
>
> I can see some justification for allowing the presented document to
> set/change the presentationId after it's loaded.  Even if it was launched
> via the Presentation API, perhaps I'm playing a game with friends and some
> pesky nearby person keeps joining, I might want to change my game mode to
> "private".  However, for any existing participants to re-join, the app will
> need to take care of distributing the new presentationId.  Not sure if
> there are other areas that assume that presentationId is static for the
> duration of the session.
>
> Mark.
>
>
>
>
> On Thu, Nov 27, 2014 at 7:20 AM, Francois Daoust <fd@w3.org> wrote:
>
>> Hi Mark,
>>
>> On 2014-11-14 18:53, Mark Scott 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 created issue 32 [1] on GitHub to track this issue, but only now start
>> to realize the full implications of your response (that took me only 2
>> weeks, you know, not so bad ;)).
>>
>> Essentially:
>> - we're discovering screens, not apps.
>> - pairing with the second screen gives permission to the user to take
>> over that screen or to join existing sessions on it, provided the user
>> knows the URL and the presentationId if there's one. The pairing mechanism
>> is out of scope of the Presentation API.
>> - more complex rules are handled at the app level.
>>
>> Rephrasing my initial scenario with that in mind:
>>
>> 1. A user starts an app directly on a "second" screen, e.g. through its
>> on-screen UI. The app runs. It has a URL. It does not have a presentationId
>> (it could have one provided through external means, e.g. in a manifest file
>> if the app is packaged somehow, but it does not have one in the generic
>> case). The app does not need to advertise itself: it already runs on a
>> screen/device that can be a "second" screen and that's enough for the
>> purpose of the Presentation API.
>>
>> 2. If another user starts an app on another device that calls
>> "startSession" with a different URL, the requesting UA will list the second
>> screen in 1 as a possible choice. The user can only take over the screen,
>> effectively killing the app running there, or sending it to the background
>> depending on how the receiving UA handles this.
>>
>> 3. If, instead, that other user starts an app on another that calls
>> "startSession" with the same URL and no presentationId, the user will be
>> given the choice between taking over the screen or joining the existing
>> session.
>>
>> 4. If the app running on the second screen wants to prevent other users
>> from joining it, it can for instance simply ignore incoming notifications.
>>
>> No change required to the Presentation API, be it on the requesting side
>> or on the receiving side. Neat!
>>
>> One remaining question on this scenario is whether an application started
>> directly on a "second" screen without a presentationId should be able to
>> declare that its presentationId is "xyz" from now on. A presentationId
>> typically represents some authentication token and the user might not be
>> logged in when the app starts. This could also be used to make an initially
>> "public" session become "private".
>>
>> This could be handled at the app level, but then the same app might want
>> to use the presentationId mechanism in the case when it is the one starting
>> the presentation session on the second screen, and would effectively have
>> to implement a similar logic in two different ways.
>>
>> Francois.
>>
>> [1] https://github.com/w3c/presentation-api/issues/32
>>
>
>