Presentations without communication channel #202

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/