W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2013

Re: Futures in WebRTC

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Mon, 03 Jun 2013 17:37:54 -0400
Message-ID: <51AD0CB2.8030006@mozilla.com>
To: public-webrtc@w3.org
On 5/28/13 5:35 AM, Anne van Kesteren wrote:
> I was asked to email a brief overview here in preparation of the call next week.
>
> == Introduction ==
>
> A future basically represents a value that may not yet have been
> computed. Since we lacked that concept thus far we've been emulating
> it with events (ondone/onerror) and callbacks (successCallback,
> failureCallback) in a somewhat mixed and adhoc fashion.
>
> Also, by making this a new type we can do interesting things with that
> type such as grouping. See http://dom.spec.whatwg.org/#futures for
> more information.
Hi everyone.

Let me admit that I read about DOM Futures for the first time today at 
https://github.com/slightlyoff/DOMFuture so it's still a bit of a 
head-rush, but a welcome one, as I'd been scratching my head about how 
our api could be made easier.

I like it! - TL;DR: Success/failure callbacks encapsulated in 
primary-return object let you write robust asynchronous code linearly.

> == Revised WebRTC IDL ==
>
> For the current features of WebRTC this would mean the IDL comes to
> look like this (I grouped the features from various drafts together
> here):
>
> * Future takePhoto();
> * Future getUserMedia(optional MediaStreamConstraints constraints);
> * Future createOffer(optional MediaConstraints constraints);
> * Future createAnswer(optional MediaConstraints constraints);
> * Future setLocalDescription(RTCSessionDescription description);
> * Future setRemoteDescription(RTCSessionDescription description);
> * Future getStats(MediaStreamTrack? selector);
>
> One bonus seems to be that you no longer have the confusion of where
> the callbacks go relative to the other arguments.
Thanks! An example would help me, so I tried to write one from this. 
Please correct me if I get this wrong of if it can be made simpler. Let 
me use this dense "simple test" I have lying around. First the old way:

function simpletest_oldapi() {
   var pc1 = new RTCPeerConnection();
   var pc2 = new RTCPeerConnection();

   navigator.GetUserMedia({video:true}, function(video1) {
     pc1.addStream(video1);
     pc1.createOffer(function(offer) {
       pc1.setLocalDescription(offer, function() {
         pc2.setRemoteDescription(offer, function() {
           pc2.createAnswer(function(answer) {
             pc2.setLocalDescription(answer, function() {
               pc1.setRemoteDescription(answer, function() {
                 finish();
               }, fail);
             }, fail);
           }, fail);
         }, fail);
       }, fail);
     }, fail);
   }, fail);
}

function simpletest_newapi() {
   var pc1 = new RTCPeerConnection();
   var pc2 = new RTCPeerConnection();

   navigator.GetUserMedia({video:true})
     .then(function(video1) {
       pc1.addStream(video1);
       return pc1.createOffer();
     })
     .then(function(offer) {
       return pc1.setLocalDescription(offer)
         .then(pc2.setRemoteDescription(offer););
     })
     .then(pc2.createAnswer())
     .then(function(answer) {
       return pc2.setLocalDescription(answer)
         .then(pc1.setRemoteDescription(answer));
     })
     .then(finish, fail);
}

Is that about right?

.: Jan-Ivar :.
Received on Monday, 3 June 2013 21:38:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:33 UTC