DOM Futures (was: Mediastream Recording implementation)

On 12/07/2013 12:04 PM, Dominique Hazael-Massieux wrote:
> Le vendredi 12 juillet 2013 à 08:55 -0700, Greg Billock a écrit :
>
>> What was the outcome of the call discussing webrtc API and Promises?
>> Any conclusions in that direction?
> There was reluctance in adopting promises for this version of
> getUserMedia given its current implementation status, and similar
> reluctance for PeerConnection due its growing current form adoption.
>
> As far as I can tell, the door was left open for Mediastream recording
> and Mediastream image capture.
>
> Dom

     I disagree. If I recall correctly, there were about 6 members 
present in the meeting. All but two of them were in favor of DOM Futures 
but the meeting ended very abruptly and without a resolution. Justin 
objected based on his perception that WebRTC 1.0 is around the corner 
and changing the API at this point would introduce "unnecessary schedule 
risk". The second person (whose name I forget) objected based on the 
fact that it's not the spec's job to mandate this coding style (which I 
assume they found objectionable) and that users should simply layer DOM 
Futures on top of the API if desired.

     In my opinion, the meeting process was deeply flawed and the 
discussion should be repeated with the goal of reaching an actual 
resolution.

     Process-aside, the vast majority of web developers I have spoken 
with have expressed serious reservations about the API in its current 
form. The large number of WebRTC wrapper APIs is further evidence of a 
problem. As much as we all would like 1.0 to be around the corner, I am 
going to have to disagree with Justin here. The API will have to undergo 
serious modifications before 1.0. As such, I do not view DOM Futures as 
an "unnecessary schedule risk:. It should be considered alongside our 
goal of improving the API design. If it has a good power/weight ratio 
then I would recommend its adoption.

Gili

Received on Saturday, 13 July 2013 05:08:24 UTC