WebAPI/PresentationAPI:CoreService: Difference between revisions
Junior Hsu (talk | contribs) (add some description of classes) |
Junior Hsu (talk | contribs) (add some description of classes) |
||
| Line 6: | Line 6: | ||
A mediator among WebAPI classes, IPC and |PresentationSessionInfo|. | A mediator among WebAPI classes, IPC and |PresentationSessionInfo|. | ||
Live in | Live in chrome process. | ||
* PresentationSessionInfo | * PresentationSessionInfo | ||
| Line 15: | Line 15: | ||
Two subclasses, |PresentationControllingInfo| and |PresentationPresentingInfo|, stands for the controller and presenter. Presenting info will establish the transport after the receiver's page ready. | 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 | Live in chrome process. | ||
* PresentationSessionTransport | * PresentationSessionTransport | ||
| Line 25: | Line 25: | ||
* PresentationIPCService | * 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 | * PresentationIPCSessionInfo | ||
Manage PresentationDataChannelSessionTransport. | |||
Only lives in e10s mode and in content process. | |||
== Call Flow Example == | == Call Flow Example == | ||
==== Establishing OOP RTCDataChannel Transport ==== | |||
==== Establishing OOP | Since RTCDataChannel should be accompanied with DOM, we should build our transport in content process in the case. Here's the procedure: | ||
# Hook handler: |SendRegisterTransportBuilderHandler| in |PresentationIPCService::StartSession| (sender) and |PresentationIPCService::NotifyReceiverReady| (receiver) hook a handler (|PresentationParent|) to |PresentationService| which lives in the chrome process. | |||
# Create a session transport builder: As chrome process ready (receive control channel|NotifyOpened| for sender; receive control channel |OnOffer| and receiver page ready |NotifyResponderReady| for receiver), |PresentationSessionInfo| create a transport builder to establish a transport. | |||
# 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. | |||
Revision as of 11:04, 24 March 2016
Introduction
The page explains the implementation detail of core service.
Architecture
- 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:
- Hook handler: |SendRegisterTransportBuilderHandler| in |PresentationIPCService::StartSession| (sender) and |PresentationIPCService::NotifyReceiverReady| (receiver) hook a handler (|PresentationParent|) to |PresentationService| which lives in the chrome process.
- Create a session transport builder: As chrome process ready (receive control channel|NotifyOpened| for sender; receive control channel |OnOffer| and receiver page ready |NotifyResponderReady| for receiver), |PresentationSessionInfo| create a transport builder to establish a transport.
- 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.