- From: Matt Hammond via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 May 2015 19:10:40 +0000
- To: public-secondscreen@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