Re: Future and getUserMedia

Dominique Hazael-Massieux wrote:
> I'm willing to take a stab at developing and maintaining a fork of
> getUserMedia that would use Futures instead of callbacks; my (possibly
> naive) current understanding is that after the initial work, the
> maintenance of the fork should be relatively low cost. This would mean
> that once we're confident we have resolved all other issues in that
> document, we could go to another Last Call specifically on the use of
> Futures before moving to Candidate Rec with one model or the other.
>
> Now, I'm not ready to do that for WebRTC quite yet, and I wouldn't want
> to do it if people (esp. implementors) feel extremely unlikely they
> would be ready to move from callback to futures at the time of
> unprefixing, or if the WGs feel this would create more confusion than
> value.

With the proposed Promise interface [1] - or with any currently existing 
Promises JavaScript library - converting getUserMedia (or any 
callback-based API) to a Promises-based approach can be done in a couple 
of lines of JavaScript [2].

On the other hand, I am genuinely interested in seeing some W3C group 
create a Promises-based specification. It's unclear how we are expected 
to extend the Promise interface right now and document our own 
Promise-based interfaces at the moment. That would be an interesting 
outcome here.

[1] http://dom.spec.whatwg.org/#promises ["Note: This feature used to be 
called Futures."]

[2] A full Promise-based getUserMedia wrapper object:

var pGUM = function(opts) {
   return new Promise(function(res) {
     navigator.getUserMedia(opts, function(stream) { res.resolve(stream) 
}, function(e) { res.reject(e) });
   });
};

Example Usage:

pGUM({video: true, audio: true}).then(function(stream, err) { /*...*/ });

Received on Wednesday, 5 June 2013 18:45:30 UTC