Re: DOM Futures (was: Mediastream Recording implementation)

On Jul 12, 2013, at 22:06, cowwoc <cowwoc@bbs.darktech.org> wrote:

> 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.

This doesn't match my recall at all but perhaps there is some ambiguity about "member". Which four members do you believe were in favor? Certainly I can name at least four people against.

Ekr

> 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 07:16:47 UTC