Re: Future and getUserMedia

On 6/5/13 6:15 PM, Dominique Hazael-Massieux wrote:
> Hi,
>
> During the teleconf today on our potential adoption of Future, there was
> a proposal that I thought was interesting: to use the removal of prefix
> as the right time to decide whether we should keep traditional callbacks
> or use Futures instead (in the model where we want to avoid maintaining
> the two models for ever).
>
> Given that current implementations ship getUserMedia and PeerConnection
> behind prefixes, and assuming they won't remove the said prefixes until
> we reach Candidate Recommendation, we have a window of opportunity to
> investigate whether Future indeed get wide adoption, wide acclaim from
> Web developers, and make the life of using our APIs significantly
> simpler.
>
> 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.
>
> Thoughts and feedback welcome,

Dom, thanks for offering to do this. After the call today I started 
thinking that perhaps we should just this, and had in mind to ask the 
editor's if they would be willing to maintain a shadow version with 
futures - but as you have volunteered I guess I will not have to ask.

I think it is especially valuable for getUserMedia to do this now as we 
hope to stabilize it relatively soon - having a Future enabled version 
alongside is really good it we would like to change at some time.

For the WebRTC I expect the API to be changed quite a bit anyway (based 
on discussions in the IETF among other things), so it is no urgency to 
do a Future enabled version IMO.

>
> Dom
>
>
>
>

Received on Wednesday, 5 June 2013 17:10:28 UTC