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.