Re: Futures in WebRTC

On 04/06/2013 2:12 PM, Adam Roach wrote:
> On 6/4/13 10:59, cowwoc wrote:
>> On 04/06/2013 11:57 AM, Eric Rescorla wrote:
>>> On Tue, Jun 4, 2013 at 8:39 AM, cowwoc <cowwoc@bbs.darktech.org 
>>> <mailto:cowwoc@bbs.darktech.org>> wrote:
>>>
>>>     As an end-user, using DOM Futures was as simple as including the
>>>     Polyfill JS. Thing is, if WebRTC is built into the browser, I'm
>>>     guessing users would expect all dependencies (i.e. DOM Futures)
>>>     to be built-in too.
>>>
>>>         Seeing as the polyfill JS is rather small. What prevents you
>>>     vendors from folding this into the browser at the same time as
>>>     WebRTC
>>>
>>>
>>> Conversely, what prevents anyone who wishes to use a futures interface
>>> from loading their own WebRTC Futures wrapper?
>>>
>>> -Ekr
>>
>>     Nothing, I guess, but it would be nice if this wrapper were 
>> officially sanctioned and maintained by the standard. You could start 
>> out this way and drop the legacy API (with callbacks) once you have a 
>> better understanding of when vendors will implement DOM Futures.
>
> Here's what I don't quite get here. The design of futures contains an 
> explicit goal of being able to be retrofitted onto existing 
> callback-based interfaces. In my book, this makes it an interesting 
> design pattern, and nothing more. I don't see why one would expect 
> vendor support for Futures any more than they would expect support for 
> Facades, Flyweights, Proxies, Chains of Responsibility, Mementos, 
> Visitors, or any number of other useful patterns.
>
> If you find futures easy to work with, go to town -- wrap 
> RTCPeerConnection in Futures and use them all over your app. It's a 
> trivial exercise. But I'm somewhat boggled why we think this rises to 
> the level of standardization.
>
> /a

     Futures are better suited to returning either success or failure 
exactly once (something we do frequently in WebRTC) and callbacks are 
better suited for repeated invocations (e.g. event listeners). I am 
proposing we use both, but limit ourselves to callbacks only for 
repeated events like onIceCandidate.

     While it is true that every user could decide to wrap WebRTC in 
Futures it would be a huge waste of time for everyone to reinvent the 
wheel. We should get a clean API by default.

     Futures is different from typical design patterns in that normally 
design patterns are an implicit part of the API. There is no Facade, 
Flyweight or Chains of Responsibility "classes" or libraries, but there 
is such a thing for Futures.

Gili