Re: VideoStreamTrack: takePhoto()

On 08/04/2013 11:17 AM, Randell Jesup wrote:
> CC-ing both lists since this is relevant to both.
>
> On 4/8/2013 6:28 AM, Robin Berjon wrote:
>> On 08/04/2013 10:27 , Harald Alvestrand wrote:
>>> Fully agreed. Your task is to convince us that the idea has technical
>>> merit.
>>
>> To be fair, in 2013, I would think that the onus of technical proof 
>> ought to fall on whoever is *rejecting* Futures. Futures are designed 
>> to be the one true way of handling precisely what Anne is proposing 
>> them for here, and I am unaware of any opposition to this consensus.
>>
>> We've been discussing this for a while. Now we have a solution. 
>> Unless there are genuine, technically grounded concerns with Futures 
>> the time to use them is now.
>>
>> Frankly, I was expecting anyone with any JS programming experience to 
>> be dancing at the availability of Futures. I'm a bit surprised at the 
>> reluctance.
>>
>
> I think the reluctance is based on concerns similar to Dom's: (quote 
> from near the beginning of this thread, copied from the WebRTC list 
> which is discussing the same thing):
>
> "Futures are still very early, and while some good thinking have been 
> put into them (as well as input from existing similar systems and 
> libraries in JavaScript), we probably shouldn't be the first group to 
> adopt them in our APIs. But once we get more confidence in their 
> stability, we should certainly assess the opportunity of making our 
> APIs future-friendly."
>
> As Harald points out elsewhere, we've already pushed the boundaries in 
> a number of ways, AND we have moved forward with real-world 
> implementations of these drafts (and getUserMedia/etc is further down 
> the pipe than WebRTC - it's fully released in Chrome, Mozilla and 
> Opera (though two are under prefixes)).  Yes, we're still making 
> breaking changes (readyState -> signalingState in WebRTC as an 
> example), but we're trying to keep them contained or trivial to update 
> to.
>
> So there's a reluctance to be the first ones to stick our necks out on 
> another new design feature/pattern.  While I haven't decided on my 
> opinion, I know some people in Mozilla support switching (without 
> having looked at what the impact of that would be, please note).
>
> We have people writing libraries based on the current APIs (and some 
> are suggesting that a single callback would be more in keeping with 
> node.js  than the current success/failure callbacks; see another thread).
>
> I looked at some of the links mentioned, and while interesting I'm not 
> entire clear on how this would affect the real-world usage of 
> application writers; I'd want to see the impact on code they'd write, 
> and evaluate how much of existing code and examples could survive this 
> change with minimal mods or with mechanical rewrites. Also, I'd want 
> to talk about how coordinated support for futures is or would be among 
> the major browser vendors.
>
> At this point I'm still skeptical of making this major a change in the 
> API this far down the path, and in doing so being the first adopter.  
> I agree that we have an unusually inherently asynchronous API that 
> would benefit from futures, which makes my first point unfortunate, so 
> I'm open to argument and also to paths forward to adopting Futures 
> that don't kill the momentum that WebRTC and getUserMedia have (i.e. 
> Dom's point).
>

     WebRTC's API surface area is pretty small. In light of this, I'm 
personally in favor of breaking API changes so long as it results in a 
cleaner/better API in the long run. In my opinion, too many APIs have 
been mutilated in the name of backwards compatibility. It's better to 
anger 1,000 developers now, than 100,000 developers in the future :)

Gili

Received on Monday, 8 April 2013 15:32:28 UTC