- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 12 Jun 2013 11:20:43 +0200
- To: public-media-capture@w3.org
On 06/05/2013 08:44 PM, Rich Tibbett wrote: > 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) { /*...*/ }); > Would it make sense for Dom to, rather than (or in addition to) maintaining a fork, maintain a wrapper library that does this thing? Then people could play with futures from a (relatively) stable reference, and figure out how they like it (for instance, I don't see where the "err" argument comes from in the argument to "then" above, but a more fleshed-out example will surely tell me).
Received on Wednesday, 12 June 2013 09:21:24 UTC