Re: Future and getUserMedia

I think this would be a good first step in terms of understanding the
actual costs and benefits associated with moving to Futures.


On Wed, Jun 5, 2013 at 9:15 AM, Dominique Hazael-Massieux <dom@w3.org>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
>
>
>
>