WebAPI/PresentationAPI: Difference between revisions

(To add more use cases for multiple CP to on PP)
(→‎Advanced Functionalities: update for latest progress)
 
(18 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== Goals ==
== Introduction ==
Presentation API enables web content to access external presentation-type displays and use them for presenting web content.
With this API, web page can initiate and control an presentation request.
 
For retrieving available devices information, please refer to [[WebAPI/PresentationDeviceInfoAPI|Presentation Device Info API]].
 
== Specification ==
* [https://www.w3.org/TR/presentation-api/ Latest W3C specification]
* [[WebAPI/PresentationAPI:Protocol Draft|Protocol Draft]]


== Use case ==
== Use case ==
See [https://github.com/w3c/presentation-api/blob/gh-pages/uc-req.md Use Cases and Requirements]
== Interface ==
* For 1-UA user agent, three preferences "dom.presentation.enabled", "dom.presentation.controller.enabled", and "dom.presentation.receiver.enabled" need to be set to true.
* For 2-UAs controlling user agent, two preferences "dom.presentation.enabled" and "dom.presentation.controller.enabled" need to be set to true.
* For 2-UAs receiving user agent, two preferences "dom.presentation.enabled" and "dom.presentation.receiver.enabled" need to be set to true.
=== Presentation ===
* [https://w3c.github.io/presentation-api/#interface-presentation WebIDL]
* No UI support for defaultRequest.
=== PresentationRequest ===
* [https://w3c.github.io/presentation-api/#interface-presentationrequest WebIDL]
* support URL with http:// protocol scheme to open web page in private browsing mode
* support URL with app:// protocol scheme to launch an packaged app installed on target B2G device
* only available in controlling browsing context
=== PresentationReceiver ===
* [https://w3c.github.io/presentation-api/#interface-presentationreceiver WebIDL]
* only available in receiving browsing context
* many-to-one session is not supported yet. [https://bugzilla.mozilla.org/show_bug.cgi?id=1195605 bug 1195605 (NEW)]
=== PresentationConnection ===
* [https://w3c.github.io/presentation-api/#interface-presentationconnection WebIDL]
=== PresentationConnectionList ===
* [https://w3c.github.io/presentation-api/#interface-presentationconnectionlist WebIDL]
* only available in receiving browsing context
=== PresentationAvailability ===
* [https://w3c.github.io/presentation-api/#interface-presentationavailability WebIDL]
* only available in controlling browsing context
== Architecture ==
Here is the high-level architecture overview of Presentation API.
[[File:Presentation_API_Architecture_overview.png|thumb|650px|Architecture overview of Presentation API]]


=== Considered Use Cases on Version landing to FxOS V3.0 ===
=== WebIDL Implementation ===
(Controlling page will be called CP and presenting page be PP)
* Provide the WebAPI interface
* One CP to one PP
* Detail at [[WebAPI/PresentationAPI:WebIDL_Implementation]]
** CP: requestSession(URL1, ID1) -> CP: there is no devices discovered yet.
** CP: requestSession(URL1, ID1) -> CP: can't reach to remote device.
** CP: requestSession(URL1, ID1) -> CP: user cancels the selection from devices list.
** CP: requestSession(URL1, ID1) -> PP: Reject this request (ex: user choice / low momory / [FxOS] no URL of app manifest is not supported)
** ---
** [basic case] CP: requestSession(URL1, ID1) -> CP: user select one device from list -> PP: page is launched -> start to communicate between CP & PP
** [Q][basic case] -> how to make sure the first call of Send() will not be missed by remote page?
** ---
** [basic case] -> CP: is crashed -> PP: session state from connected to disconnected -> CP: joinSession(URL1, ID1) -> CP: is automatically bound to previous PP -> PP: session state from disconnected to connected.
** [basic case] -> CP: is crashed -> PP: session state from connected to disconnected -> CP: joinSession(URL1, ID2) or joinSession(URL2, ID1) -> [Q] CP: reject this call?
** [basic case] -> CP: is crashed -> PP: session state from connected to disconnected -> CP: requestSession(URL1, ID1) -> CP: user select the same device from list -> [Q] PP: close old page -> PP: restart a new page
** [basic case] -> CP: is crashed -> PP: session state from connected to disconnected -> CP: requestSession(URL1, ID1) -> CP: user select a different device from list -> PP: nothing -> New-PP in different device: new page is launched -> [Q] Is it possible of CP calling joinSession(URL1,ID1) to PP again?
** ---
** [basic case] -> CP: page is closed gracefully -> [Q] PP: page is closed as well.
** [basic case] -> PP: page is closed gracefully -> [Q] CP: session state from connected to disconnected
** [basic case] -> PP: page is crashed -> [Q] CP: ?


* One CP to multiple PP
=== Core Service ===
** CP: requestSession(URL1, ID1) to device 1 -> PP1: page is presented -> CP: requestSession(URL1, ID1) to device 2 -> PP1: is page closed or session state is changed? -> PP2: page is presented.
* Maintain the session state and app-to-app transportation channel
** CP: requestSession(URL1, ID1) to device 1 -> PP1: page is presented -> CP: requestSession(URL1, ID2) to device 2 -> PP1: nothing changed -> PP2: page is presented.
* Handle the session setup / reconnect / terminate procedure
* Live in chrome process
** except for DataChannelTransportBuilder and DataChannelTransport
* Detail at [[WebAPI/PresentationAPI:CoreService]]


* Multiple CP to one PP
=== Device Manager ===
** [basic case] -> CP in different device: request/joinSession(URL1, ID1) -> PP: reject this new session.
* Load registered device provider at start-up automatically
** [FxOS] CP (WebApp A): requestSession(URL1, ID1) to device 1 -> PP1 (WebApp): page is presented -> open another CP (WebApp A) -> Currently FxOS can't create two instances of the same Web App in the same time.
* Provide device list and firing availability event
** CP (URL A in tab A): requestSession(URL1, ID1) to device 1 -> PP1: page is presented -> open another CP (URL A in tab B): requestSession(URL1, ID1) to device 2 -> PP2: page is presented
* Live in chrome process
** Based on use case above -> tab1 & tab 2 are all crashed -> open another CP (URL A in tab C): joinSession(URL1, ID1) -> (Q) whether the session from device 1 or device 2 should be resumed?
=== Device Provider ===
* Implement device discovery mechanism
* Handle control channel setup procedure
* Live in chrome process
=== Browser/System UI Glue ===
* Handle device selection and application launch
* Live in chrome process


=== Not Considered Use Cases Yet ===
== Development Plan ==
* One presenting page can accept multiple sessions from controlling pages.
=== Basic Functionalities ===
* (FxOS) The same WebApp can be requested multiple times as multiple instances in presenting side.
*Stage 1: Enable 2-UAs mode on Firefox OS, for privilege apps only.
** Implement Presentation API ([https://bugzilla.mozilla.org/show_bug.cgi?id=1069230 Bug 1069230 (RESOLVED)] and [https://bugzilla.mozilla.org/show_bug.cgi?id=1148307 Bug 1148307 (RESOLVED)])
** Provide MDNS provider on Firefox OS ([https://bugzilla.mozilla.org/show_bug.cgi?id=1115480 Bug 1115480 (RESOLVED)])
** Provide device selection/configuration UI on Firefox OS ([https://bugzilla.mozilla.org/show_bug.cgi?id=1161440 Bug 1161440 (RESOLVED)])
*** The initial version of UI should be simple without detailed security design, but keep pref off after check-in
*** pref on after security team confirmation.
*Stage 2: Integrated with media fling on Firefox for Android.
** Provide MDNS provider on Firefox for Android. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1158029 Bug 1158029 (RESOLVED)])
** Add Presentation Device as a fling service device. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1129785 Bug 1129785 (RESOLVED)])
*Stage 3: Enable 1-UAs mode on Firefox OS for HDMI display.
** Enable multi-window for HDMI ([https://bugzilla.mozilla.org/show_bug.cgi?id=1116089 Bug 1116089 (RESOLVED)])
** Implement HDMI device provider ([https://bugzilla.mozilla.org/show_bug.cgi?id=1208417 Bug 1208417 (RESOLVED)])
** Make Gaia use presentation API ([https://bugzilla.mozilla.org/show_bug.cgi?id=1235124 Bug 1235124 (RESOLVED)])
*Stage 4: Enable 1-UAs mode in HTTPS web pages on Firefox For Android.
** Enable 1-UA mode for Chromecast ([https://bugzilla.mozilla.org/show_bug.cgi?id=1252788 Bug 1252788 (ON GOING)]).
** Provide device selection/configuration UI on Firefox for Android ([https://bugzilla.mozilla.org/show_bug.cgi?id=1232105 Bug 1232105 (RESOLVED)]).
** Change permission model for Presentation API ([https://bugzilla.mozilla.org/show_bug.cgi?id=1278205 Bug 1278205 (RESOLVED)]).
*Stage 5: Enable in HTTPS web pages for Firefox desktop.
** Provide MDNS provider on all supported desktop platforms
*** Windows ([https://bugzilla.mozilla.org/show_bug.cgi?id=1239909 Bug 1239909 (NEW)])
*** Linux ([https://bugzilla.mozilla.org/show_bug.cgi?id=1225736 Bug 1225736 (NEW)])
*** Mac OSX ([https://bugzilla.mozilla.org/show_bug.cgi?id=1225726 Bug 1225726 (RESOLVED)])
** Provide device selection/configuration UI on Firefox ([https://bugzilla.mozilla.org/show_bug.cgi?id=1289974 Bug 1289974 (ON GOING)]).


== Proposal ==
=== Advanced Functionalities ===
* Enable 1-UA mode for DIAL app to increase device compatibility
* Support different URL scheme, e.g. data, file
* Support multiple session (n:1) to support wider user scenario, e.g. multi-player game. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1195605 Bug 1195605 (NEW)])

Latest revision as of 07:01, 12 October 2016

Introduction

Presentation API enables web content to access external presentation-type displays and use them for presenting web content. With this API, web page can initiate and control an presentation request.

For retrieving available devices information, please refer to Presentation Device Info API.

Specification

Use case

See Use Cases and Requirements

Interface

  • For 1-UA user agent, three preferences "dom.presentation.enabled", "dom.presentation.controller.enabled", and "dom.presentation.receiver.enabled" need to be set to true.
  • For 2-UAs controlling user agent, two preferences "dom.presentation.enabled" and "dom.presentation.controller.enabled" need to be set to true.
  • For 2-UAs receiving user agent, two preferences "dom.presentation.enabled" and "dom.presentation.receiver.enabled" need to be set to true.

Presentation

  • WebIDL
  • No UI support for defaultRequest.

PresentationRequest

  • WebIDL
  • support URL with http:// protocol scheme to open web page in private browsing mode
  • support URL with app:// protocol scheme to launch an packaged app installed on target B2G device
  • only available in controlling browsing context

PresentationReceiver

PresentationConnection

PresentationConnectionList

  • WebIDL
  • only available in receiving browsing context

PresentationAvailability

  • WebIDL
  • only available in controlling browsing context

Architecture

Here is the high-level architecture overview of Presentation API.

 
Architecture overview of Presentation API

WebIDL Implementation

Core Service

  • Maintain the session state and app-to-app transportation channel
  • Handle the session setup / reconnect / terminate procedure
  • Live in chrome process
    • except for DataChannelTransportBuilder and DataChannelTransport
  • Detail at WebAPI/PresentationAPI:CoreService

Device Manager

  • Load registered device provider at start-up automatically
  • Provide device list and firing availability event
  • Live in chrome process

Device Provider

  • Implement device discovery mechanism
  • Handle control channel setup procedure
  • Live in chrome process

Browser/System UI Glue

  • Handle device selection and application launch
  • Live in chrome process

Development Plan

Basic Functionalities

Advanced Functionalities

  • Enable 1-UA mode for DIAL app to increase device compatibility
  • Support different URL scheme, e.g. data, file
  • Support multiple session (n:1) to support wider user scenario, e.g. multi-player game. (Bug 1195605 (NEW))