Re: Allow page to designate itself as presentation session

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

Received on Thursday, 27 November 2014 15:20:27 UTC