Re: Futures in WebRTC

On 2013-05-28 11:35, 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.
>
> == 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.

Anne, can you comment on the preferred behavior when an object returns a 
Future but enters the closed state (where it basically is useless and 
throws InvalidState exceptions when interacted with) before the Future 
is resolved. Should the Future be left in the pending state or should it 
be rejected?

/Adam

Received on Tuesday, 4 June 2013 13:02:04 UTC