Re: Futures in WebRTC

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