Re: VideoStreamTrack: takePhoto()

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

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Monday, 8 April 2013 15:20:01 UTC