Presentations without communication channel

[tidoust]

The Presentation API assumes that the user agent handles the discovery, control and the establishment of the communication channel. In issue #61 (Add facility for the opening page to add cloud paired screens as presentation targets), we have already started to discuss how the Web app could perhaps take care of all these steps and register online screens under its control with the user agent, so that the user be prompted only once.

I wonder whether something in-between could be useful as well, in other words a way to let the user agent handle the discovery and control, while the Web app takes care of the communication channel, typically going through some backend server.

In terms of API, the change I have in mind would be a new options parameter for the PresentationRequest constructor that Web apps could use to set an isChannelOptional flag. When that flag is set, the user agent would not need to establish a communication channel between the contexts and could thus list additional devices or mechanisms that could be used for the presentation. By default, this flag is not set, only displays with which the user agent may establish a communication channel are listed, and Web apps can continue to assume that such a channel will eventually be created. Other changes may perhaps be needed, or this may be doable differently.

Examples of presentation mechanisms that could be implemented if such a flag existed:

1. HbbTV 2.0 (as noted in Investigate possible compatibility with HbbTV #67, the receiving Web app will need to establish the communication channel with the local WebSocket server on its own)
2. Other DIAL applications, at least pending a proper mechanism to establish a communication channel
3. QR code. So passé, I know...
4. Broadcasting the URL over a Bluetooth LE beacon, à la Physical Web.
5. Tapping devices using NFC.
6. Using Push notifications on devices on previously paired devices, through a Service Worker.

Some of these mechanisms may be implemented at the app-level (Push API, QR code) and are thus more linked to issue #61. Others may be doable in the future (NFC) or may trigger additional privacy concerns (e.g. broadcasting the URL) as they are not discovery-based but rather invitation-based. In some cases, there is no guarantee that the controlling device will even know that a receiving device has loaded the URL or that only one such device will do so.

However, practically speaking, all of these mechanisms would allow a Web application to present web content on a secondary display.

I experimented with @dontcallmedom within the MediaScape EU project on some of these mechanisms in an updated version of the Presentation API polyfill that I had written for the Slidy Remote demo. The code of this new polyfill is available at:

https://mediascape.github.io/presentation-api-polyfill/

[tidoust]

See relevant discussion at TPAC F2F:
http://www.w3.org/2015/10/28-webscreens-minutes.html#item07

[tidoust]

I agree with @anssiko (in #276) that this can be considered a new candidate feature for v2 at this stage and have updated the labels accordingly.

[tidoust]

For reference, see related discussion at TPAC

[markafoltz]

Labeling for possible followup at TPAC.

[markafoltz]

From https://www.w3.org/2017/11/06-webscreens-minutes.html#x18:

ACTION: @mfoltzgoogle to check the spec language is aligned with "presentation started but cannot communicate, then close connection"

[markafoltz]

At least for the DIAL (and presumably HbbTV 2.0) use cases, closing the connection leaves the controlling page unable to terminate the presentation (which is possible via DIAL). So I think closing the connection immediately is actually not the right solution for those two.

For the other use cases, it sounds like the presentation URL is transferred/navigated to another device, and there's no further control possible through the Presentation API. I will put up a pull request to accommodate those scenarios in the spec which doesn't require API changes.

[markafoltz]

As discussed in #484, there's no way to accommodate these scenarios without some kind of API change. Since Chrome has no plans to ship presentation receivers that don't have some kind of communication possible, then I propose to close this issue out.

Another way to broaden the set of devices reachable from the Presentation API would be to make progress on #61, which could accommodate site-defined "presentation" mechanisms.