W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2012

Re: Draft of alternative JSEP API proposal

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Sat, 17 Mar 2012 07:37:09 +0100
Message-ID: <4F643115.4020508@ericsson.com>
To: Neil Stratford <nstratford@voxeo.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 03/16/2012 05:11 PM, Neil Stratford wrote:
> Hi,
> On 16 Mar 2012, at 15:10, Stefan Hakansson LK wrote:
>>>> - While the browser maintaining the signalling state machine
>>>> and invoking the JS using callbacks makes the simple case very
>>>> easy, it can easily result in spaghetti code for anything more
>>>> complicated where the state machine needs to be maintained by
>>>> the JS application. You end up with a split system where you
>>>> are waiting for a callback which could have just as easily been
>>>> synchronous (and a lot easier to understand).
>> I think the reason for asynchronous callbacks is to not stop the JS
>> execution (which would lead to unresponsive apps). E.g., if the
>> signaling messaged could be delivered immediately on request that
>> would not be needed. I don't know if that is possible or not (guess
>> it depends a bit on the underlying implementation and if new
>> candidates must be obtained and so on).
> I agree that we would never want to block, but is there anything
> besides candidate gathering that could block? The candidate state
> machine needs to be driven by the browser, but codec negotiation etc
> presumably would never block. (or can it?)

I have the same feeling, but must say I don't know. Could it be that in 
certain implementations this is handled by resources in the OS, and 
those resources can be temporarily blocked by other applications using 
them? And in that case for so long that it matters?

Received on Saturday, 17 March 2012 06:37:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC