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.

Discovery
* 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

Launch:
* 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

Resumption:
* 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

Communication:
* 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.

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

Resumption/Joining:
* 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
See 
https://github.com/w3c/presentation-api/issues/67#issuecomment-101780142
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