- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Sat, 17 Mar 2012 07:37:09 +0100
- 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? Stefan
Received on Saturday, 17 March 2012 06:37:35 UTC