W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2013

Futures in WebRTC

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 28 May 2013 10:35:22 +0100
Message-ID: <CADnb78j6xPXX81v=jAP9z7BsK=YZRmGkMDc-eiHUpdCzF6WV8w@mail.gmail.com>
To: "public-media-capture@w3.org" <public-media-capture@w3.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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.

== 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.

== Open issues ==

Futures are not completely baked yet, but the basic idea of a value
that may not yet have been computed and either turns out to be an
error of sorts on asynchronous inspection or a real value has wide
consensus.


--
http://annevankesteren.nl/
Received on Tuesday, 28 May 2013 09:35:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 28 May 2013 09:35:56 UTC