Re: Futures in WebRTC

     That's surprising. What about https://github.com/slightlyoff/Promises?

     I wonder if this was an implementation-specific problem or 
something that is inherit to Futures? I'd be surprised if it's the latter.

Gili

On 05/06/2013 10:52 AM, David Beckwith wrote:
> By the way, just for reference, a nice implementation of futures in 
> Javascript can be found here:
>
> https://github.com/kriskowal/q
>
> However, one caveat that I found is that using this library slowed 
> down my Node.js server from about 4000 requests per second to about 
> 150 requests per second.
>
> Not sure if supporting futures in C++ would necessarily incur such a 
> performance hit, but maybe it's something to consider.
>
> I love the readability, error bubbling, consolidation of error 
> handling, and flow of control advantages the promises pattern gives, 
> but the performance hit was substantial in my Node.js experience.
>
>
> On Wed, Jun 5, 2013 at 6:03 AM, Jan-Ivar Bruaroey <jib@mozilla.com 
> <mailto:jib@mozilla.com>> wrote:
>
>     I would ask it differently: Would our API gain from using a
>     pattern like this? Take EventTarget, another pattern. Clearly our
>     API is better from using EventTarget.
>
>     Personally, I find the benefits quite persuasive: simpler
>     parameter list, use of primary-return, error bubbling, suite of
>     relevant utility methods, and last but not least, this pattern for
>     dealing with async behaviors seems to fit our bill. Documentation
>     benefit: return a Future, link to other standards doc, nothing to
>     explain.
>
>     Great stuff.
>
>     Is this the right pattern? DOM Futures is not EventTarget yet. At
>     least three attempts preceded it. It is early so there is risk.
>
>     Should we break our already-shipped API to embrace this pattern
>     now? Clearly we'd like to avoid that, and if our API can easily be
>     wrapped, a good question is: Why? Selfishly we're no worse (and
>     not better) off than other APIs that, frankly, Futures has to
>     catch up to.
>
>     So yes, I would say there is gain, but it should be weighed
>     against risk and loss of compatibility. I don't see a conflict in
>     holding those opinions.
>
>     At the very least, I hope tomorrow we can remove any obstacles (if
>     there are any) to wrapping Futures around our API.
>
>     .: Jan-Ivar :.
>
>
>     On 6/4/13 2:39 PM, cowwoc wrote:
>>     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
>
>
>     -- 
>     .: Jan-Ivar :.
>
>