WebAPI/PresentationAPI

From MozillaWiki
< WebAPI
Revision as of 12:13, 3 November 2015 by Schien (talk | contribs) (Create architecture section)
Jump to navigation Jump to search

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.

Use case

Considered Use Cases on Version landing to FxOS V3.0

  • Device Discovery
    • Once a remote device supports multiple connectivity media, how to show devices list to user? ex: A TV supports HDMI/WiFi Display/Other protocol for two UA case. One possible way is just to show device with appending keyword.

(Controlling page will be called CP and presenting page be PP)

  • One CP to one PP
    • 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
    • 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.
    • 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.
  • Multiple CP to one PP
    • [basic case] -> CP in different device: request/joinSession(URL1, ID1) -> PP: reject this new session.
    • [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.
    • 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
    • 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?

Not Considered Use Cases Yet

  • One presenting page can accept multiple sessions from controlling pages.
  • (FxOS) The same WebApp can be requested multiple times as multiple instances in presenting side.

Interface

Presentation

  • WebIDL
  • defaultRequest is not supported yet.

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 device
    • can only launch packaged apps with "presentation" permission declared
  • session reconnect is not supported yet. bug 1197690 (NEW)

PresentationReceiver

PresentationConnection

PresentationAvailability

Architecture

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

WebIDL Implementation

  • provide the WebAPI interface

Core Service

  • maintain the session state and app-to-app transportation channel
  • handle the session setup procedure
  • lives in chrome process

Device Manager

  • automatically loading registered device provider at start-up
  • providing device list and firing availability event
  • lives in chrome process

Device Provider

  • implement device discovery mechanism
  • handle control channel setup procedure
  • lives in chrome process

Browser/System UI Glue

  • handling device selection and application launch
  • lives in chrome process

Development Plan

Basic Functionalities

  • Stage 1: Enable 2-UAs mode on Firefox OS, for privilege apps only.
  • Stage 2: Integrated with media fling on Firefox for Android.
  • Stage 3: Enable 1-UAs mode on Firefox OS for HDMI and Wifi display.
  • Stage 4: Enable in HTTPS web pages for all platforms.
    • Provide MDNS provider on Windows, Linux, Mac OSX.
    • Provide device selection/configuration UI on Firefox and Firefox for Android.
    • Change permission model for Presentation API.

Advanced Functionalities

  • Enable 1-UA mode for Chromecast/DIAL app to increase device compatibility
  • Support different URL scheme, e.g. data, file
  • Support session resume for improving cross device task continuity
  • Support multiple session (n:1) to support wider user scenario, e.g. multi-player game.