Re: Allow page to designate a default presentation URL

On Tue, Nov 25, 2014 at 6:38 PM, Mark Scott <markdavidscott@google.com>
wrote:

> The only comment I had in reviewing this thread was about the wording
> around joining an existing session with browser-initiated presentations:
>
> > Does it make sense to scope this "implicit invocation" (throught the UA
>>>> UI) use case more tightly to new sessions only? For joining to existing
>>>> sessions, the programmatic API could be used.
>>>> >
>>>> > Are both the "implicit invocation" and the programmatic API
>>>> attempting to address the same use cases i.e. are we striving for feature
>>>> parity between the two? If so, it may cause problems since the programmatic
>>>> API tends to be more expressive by design.
>>>>
>>>> If there's an existing presentation session going on, the page should
>>>> be able to find the presentation id itself (i.e. via the local storage) and
>>>> join the session without any user action. There's no need for the default
>>>> presentation URL in this case.
>>>>
>>>
>>> I agree; I don't see a need to support programmatic join behavior in
>>> this scenario.  We do need to ensure that a page can try (and fail) to
>>> programmatically join a presentation before setting a default presentation
>>> URL, so the page can prioritize auto-resumption vs. initiation of a new
>>> presentation session.
>>>
>>
> IMO there are scenarios where it is desirable to support UA-initiated
> joining of an existing session.
>
> A common scenario can occur with a single device.  Let's say I can tap
> (via NFC) a display to initiate presentation.  If I reload/restart/reboot
> for some reason, and the presentation keeps running, I should be able to
> reconnect to the session simply by tapping a second time.
>
> In a more complex scenario, we might have two users of a photo site, with
> the same presentation URL (and ID, if used) served to each users UA.  The
> first user might tap the display to create the presentation session; when
> the second user taps, they're joined to the session (at which point they
> can both contribute photos to a shared slideshow, or something to that
> effect).
>
> In both cases, this is a "new" session from the perspective of the page.
> It's consistent with 5.1 in the spec, which discusses manual connections to
> existing presentations.  However, it might be necessary to allow the
> presentation ID to be specified along with the default presentation URL for
> this scenario to work.
>

Mark S.

In the first scenario wouldn't the page try to join the existing session
when it loaded regardless of the tap (by persisting the presentation URL
and ID when the session was created)?

In the second scenario, the second participant needs to create a new
PresentationSession for its controlling page, so it would call
requestSession(URL, ID) where the URL and ID are passed via NFC.

If we want to bypass screen selection in the user agent based on certain
user actions (like tapping a display), that would be a different scenario I
haven't explored yet in the context of this spec.

m.



>
> Mark.
>