- 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