Re: Allow page to designate a default presentation URL

Hey Mark,

In the first scenario, it's possible that the page might always try to join
a session on restart, but it might not always want to do this.  For
example, I start Netflix upstairs for my kids, but later return to the
Netflix site and would like to watch something on my entertainment system
downstairs.  The Presentation API handles such apps well - startSession()
lets me either reconnect to my kids session or start a new one, depending
on what device I choose - I'm just suggesting that the same outcomes be
possible if I initiate presentation via the UA (e.g. via NFC tap, or some
other gesture).

In the second case, I understand that if the page can get the presentation
ID, it can join the session.  I just felt that the case of initiating
presentation via the UA (not via API) should handle this case as well.

I may have confused things using the example of NFC tap.  I was only using
this as an example of a user gesture processed by the UA (vs. an
interaction with the page that could trigger page-initiated use of the
presentation API).  The simpler example would be just clicking on a
"present" button in the browser toolbar, and picking a specific device.

Mark.

On Wed, Nov 26, 2014 at 9:06 AM, mark a. foltz <mfoltz@google.com> wrote:

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