W3C home > Mailing lists > Public > public-secondscreen@w3.org > May 2015

Re: [presentation-api] Investigate possible compatibility with HbbTV

From: Matt Hammond via GitHub <sysbot+gh@w3.org>
Date: Wed, 13 May 2015 19:10:40 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-101780142-1431544239-sysbot+gh@w3.org>
Here is a summary of the behaviour and capabilities of the application
 launch and communication mechanisms in HbbTV 2.0, with a view to how 
they relate to the functionality in the presentation API:

HbbTV 2.0 allows another device on the home network to request that 
the TV launch a URL in the HbbTV engine. This engine is basically a UA
 with an HbbTV defined profile of HTML5 plus TV specific extensions.

* Begin the same as DIAL (HbbTV 2.0 incorporates DIAL) using SSDP and 
retrieving the UPnP device description
* Then query the existence of an "HbbTV" DIAL application to determine
 if device has HbbTV capabilities.
  * This query also returns the WebSocket URL needed to use the 
message communication mechanism in HbbTV

* DIAL launch request for "HbbTV" DIAL app. Post body contains HbbTV 
launch parameters
  * Minimum required is the URL of the HTML page to launch.
  * Must also provide integer `appId` and `orgId` if the HTML page 
wants to use HbbTV broadcast TV features

* Can determine (using DIAL) if the HbbTV engine is running; but not 
what URL it is presenting.
* No presentation session identifier provided. Will not be able to 
tell if HbbTV engine has been re-started (with a different or the same
 presentation) since the UA last checked

* HbbTV device provides a means of establishing a transparent non-TLS 
WebSocket connection. Both the Javascript running in the HbbTV engine,
 and the Javascript in the other device connect to a server built into
 the TV that relays the messages between paired-up connections.
* When connecting, URL must be suffixed with an `app-endpoint` by both
 parties. Only if they match will the connections be "paired" and 
start to relay messages. A message is sent to both parties notifying 
them when pairing takes place.
* If a connection is not yet paired, it will not be possible to tell 
which of the following is the reason
  * Presentation on the TV not yet loaded and running
  * Different presentation on the TV from the one we expected
  * No webpage being presented on the TV.
* The presentation on the TV controls whether it wishes to open/close 
communication connections, so it cannot be used as a reliable way of 
determining of the presentation is running/terminated on the TV.

* No guaranteed support. Stopping the HbbTV engine would be done using
 DIAL where it is an optional feature.

* Can determine in HbbTV engine is running, but not what presentation 
it is showing
* Can try to establish communication (using the correct 
`app-endpoint`) but can only detect success.

Summary of compatibility:
* Discovery and launching mechanisms map well to existing availability
 checking and sessions starting.
* Message communication mechanism maps to send/post and receive 
functionality (it is basically WebSockets) but only if the correct 
`app-endpoint` string can be provided
* For the second screen presentation to use broadcast TV functionality
 specific to HbbTV, additional per URL parameters must be passed in 
the launch process.
* Closing/terminating a session can break the communication link, but 
cannot force the presentation on the TV to be terminated.
* Resumption/joining a session is possible if the same `app-endpoint` 
is used, but this does not guarantee you are communicating with the 
same presentation as before.
* Communication is always unencrypted and cannot be trusted as there 
is no mechanism for the UA to authenticate and trust the actions of 
the HbbTV device

GitHub Notif of comment by matt-hammond-bbc
Received on Wednesday, 13 May 2015 19:10:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 13 May 2015 19:10:49 UTC