-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial version of the interoperability document #175
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
# Assess interoperability of Presentation API implementations | ||
|
||
This document discusses the interoperability of potential Presentation API implementations in particular interoperability | ||
between user agents in case of [2-UA implementations][2ua] and between user agents and presentation displays in case of [1-UA implementations][1ua]. | ||
For this, state of the art technologies and standards that may be useful to implement the Presentation API will be considered. | ||
|
||
## Interoperability between user agents (2-UA) | ||
|
||
The following diagram shows an overview of the main components for the 2-UA implementation. Each of the user agents implements | ||
part of the Presentation API (for controlling browsing context or presenting browsing context). To ensure interoperability | ||
between user agents running on controller devices and user agents running on presentation devices the following aspects should be considered: | ||
|
||
* **Discovery**: to discover presentation devices, the controlling user agent should use the same technology as the presenting | ||
user agent uses to advertise itself. **Potential technologies**: SSDP, mDNS or BLE (BLE Beacon) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It would be a good idea to include reference URLs for each of the technologies mentioned. For example SSDP should reference the uPnP spec. |
||
* **Launch**: after discovery, the controlling user agent should know how to launch a new presentation or join an existing one. | ||
Common message formats should be also used. **Potential technologies**: DIAL (uses SSDP for discovery), Google Cast (part of it). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should specifically call out the HBBTv 2.0 spec (referencing GH Issue #67). User agents that support it will be able to present arbitrary URLs (not just pre-installed DIAL applications). |
||
* **Communication**: also for communication both user agents should use same technologies/protocols to ensure interoperability. | ||
**Potential technologies**: WebSockets, WebRTC, Raw Socket, Google Cast (part of it) | ||
* **Signaling**: common language and message formats (e.g. using JSON or XML) should be used to exchange signaling information between the two user agents. | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would add security to implemenent authentication of the display and privacy of the presentation messaging. |
||
![2-UA implementation][2ua-img] | ||
|
||
## Interoperability between user agents and presentation displays (1-UA) | ||
|
||
The following diagram shows an overview of the main components for the 1-UA Implementation. There are less requirements | ||
as in the 2-UA case to ensure interoperability between controlling user agents and presentation displays. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It might be helpful to list the specific protocol components, as was done above. In my mind this includes:
|
||
The controlling user agent implements the Presentation API for both controlling and presenting browsing contexts and the presentation | ||
page is rendered in silent mode (not visible for the user). The user agent captures the UI output of the presentation page rendered | ||
in silent mode and sends the frames to a presentation device like a projector or wireless display. This means the user agent and the | ||
presentation device should use a common streaming technology to ensure interoperability. More than likely, the user agent will use System APIs | ||
offered by the OS to show content on the presentation device. But other technologies not offered directly by the OS are also possible, for example | ||
Google Cast extension for chrome supports Tab cast to Chromecast using WebRTC. **Potentials Technologies**: HDMI, Intel WiDi, Miracast, Airplay, MHL. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. WebRTC is a potential technology here. |
||
|
||
![1-UA implementation][1ua-img] | ||
|
||
[1ua]: http://w3c.github.io/presentation-api/#1-ua | ||
[2ua]: http://w3c.github.io/presentation-api/#2-ua | ||
[1ua-img]: ./images/interoperability-1ua.png | ||
[2ua-img]: ./images/interoperability-2ua.png |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a nit-pick, but wrapping the text with shorter lines will make future diffs easier to read.