- From: Robin Raymond <robin@hookflash.com>
- Date: Thu, 24 Apr 2014 23:21:22 -0400
- To: "public-ortc@w3.org" <public-ortc@w3.org>
Pursuant to the last ORTC public meeting:
https://docs.google.com/presentation/d/1ZP2bt_coR47Y3O2Mf003sD5n8mx8CLClhZs3YSX-E-Y/edit?usp=sharing
Slide 23.
I propose we should add the concept object "RTCSession".
The object could be like this:
[Constructor()]
interface RTCSession {
static RTCSession defaultSession();
};
defaultSession - obtain a reference to the default RTC session object
for the current web page [sandbox??]
(^please, someone come up with a more refined definition)
The idea is that you can construct objects without specifying the
RTCSession object, as the default for the current web page session will
be used.
For example,
var myTransport = new RTCIceTransport(myRole); can be used and the
default web page "RTCSession" object would be used.
But the session could be explicit so:
var mySession = new RTCSession();
var myAudioTransport = new RTCIceTransport(mySession, myRole);
var myVideoTransport = new RTCIceTransport(mySession, myRole);
... would mean these RTCIceTransports are tied to a particular
RTCIceTransport session distinct from the "default" or any other
RTCSession created.
This would resolve the "freezing" foundation problem as discussed in the
ORTC meeting where implicit freezing rules could be done except we had
no idea what RTCIceTransport objects were related to other
RTCIceTransport objects vs RTCIceTransport objects that need their own
private freezing relationships.
I can see this RTCIceTransport being an optional constructor option for
RTCIceTransport but perhaps we'll need it for other objects too in the
future to group them together into a common session (or perhaps not).
Bottom line though is the interface causes no additional programming
pain for the simple use cases who can simply ignore this session option
(and thus get the page default) but those who need to be precise with
the freezing rules can use this RTCSession object to explicitly define
RTCIceTransport relationships.
Further, I believe maintaining compatibility shims with WebRTC 1.0 peer
connection to make ensure groupings and freezing are respected will need
some way to collect the RTCIceTransport object relationships together
for the sake of freezing.
On and I future propose we can use implicit freezing rules as a result
of adding the "RTCSession" object as we discussed in the last ORTC
meeting (i.e. freezing upon common "local" + "remote" foundations with
the order of freezing dependency determined by RTCIceTransport object
creation).
-Robin
Received on Friday, 25 April 2014 03:21:51 UTC