[presentation-api] Presentations without communication channel

tidoust has just created a new issue for 
https://github.com/w3c/presentation-api:

== Presentations without communication channel ==
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 #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/



See https://github.com/w3c/presentation-api/issues/202

Received on Tuesday, 6 October 2015 20:01:37 UTC