WebAPI/PresentationAPI:CoreService

Introduction

The page explains the implementation detail of core service.

Architecture

Architecture of Presentation API Core Service (In process case)

Architecture of Presentation API Core Service (Data Channel OOP case)

PresentationService

A mediator among WebAPI classes, IPC and |PresentationSessionInfo|.

Live in chrome process.

PresentationSessionInfo

Maintain grotty details around session transports, receiver page and connection state.

Session infos use the established control channel to negotiate the SDP of session transport and create a transport builder to do the transport establishment.

Two subclasses, |PresentationControllingInfo| and |PresentationPresentingInfo|, stands for the controller and presenter. Presenting info will establish the transport after the receiver's page ready.

Live in chrome process.

PresentationSessionTransport

Maintain the underlying transport. We have TCP transport now and work on RTCDataChannel transport.

TCP transport lives in Chrome process. RTCDataChannel lives with the DOM. That is, live in content process in e10s mode.

PresentationIPCService

A mediator between IPC and WebAPI. Also manage PresentationIPCSessionInfo if the underlying transport is RTCDataChannel.

Only lives in e10s mode and in content process.

PresentationIPCSessionInfo

Manage PresentationDataChannelSessionTransport.

Only lives in e10s mode and in content process.

Call Flow Example

Establishing OOP RTCDataChannel Transport

Since RTCDataChannel should be accompanied with DOM, we should build our transport in content process in the case. Here's the procedure:

1. Hook handler: |SendRegisterTransportBuilderHandler| in |PresentationIPCService::StartSession| (controller) and |PresentationIPCService::NotifyReceiverReady| (presenter) hook a handler (|PresentationParent|) to |PresentationService| which lives in the chrome process.
2. Create a session transport builder: As chrome process ready (receive control channel|NotifyOpened| for controller; receive control channel |OnOffer| and receiver page ready |NotifyResponderReady| for presenter), |PresentationSessionInfo| create a transport builder to establish a transport.
3. Build a transport in content process: The transport builder is |PresentationParent| hooked by first step. It will triggered an IPC call to |PresentationIPCService| and build the underlying RTCDataChannel in the content process. It will call back to |PresentationService| the result of building.

Receiving UA

handle presentation request

sequence diagram of handling session request on receiving UA

• establishing TCP Transport

1. PresentationService observe incoming presentation request via "presentation-session-request" topic
2. create receiving browser context via nsIPresentationUIGlue and navigate to presentation URL
   1. presented content should be loaded in a browser element with "mozpresentation" attribute set to the requested presentation URL
3. a (windowId, presentationId) mapping will be created at content side while document begins to load
   1. corresponding session info object will be removed if failed to load within time limit
4. In parallel, establish transport channel between controlling page and presented content

monitor incoming connection

sequence diagram of monitoring incoming connection on receiving UA

• monitor incoming connection

1. register PresentationReceiver as a RespondingListener to PresentationService while navigator.presentation.receiver.connectionList is touched first time.
2. PresentationService will report the available presentationId via nsIPresentationRespondingListener::NotifySessionConnect.
3. corresponding PresentationConnection object will be created in connecting state and register it as a SessionListener to PresentationService.
4. transport channel state will be sent to presented content once PresentationConnection object is created
   1. if fail to create transport channel, PresentationConnection state should be set to 'closed'