Re: Mozilla/Cisco API Proposal - listening

On Jul 11, 2011, at 15:09 , Ian Hickson wrote:

>> 
>> 	- We added a LISTENING state (this means the PeerConnection can call
>> accept() to open an incoming connection, the state is entered into by calling
>> listen()), and added an open() call to allow a peer to explicitly "dial out".
> 
> Generally speaking this is an antipattern, IMHO. We learnt with 
> XMLHttpRequest that this kind of design leads to a rather confusing 
> situation where you have to support many more state transitions, and it 
> leads to very confusing bugs. This is why I designed the PeerConnection() 
> object to have a constructor and to automatically determine if it was 
> sending or receiving (and gracefully handle the situation where both 
> happen at once). It makes the authoring experience much easier.


I have no love for the unix sockets metaphor and don't care how we solve the problem but I think there are some problems to be solved still here. 

Ian, I apologize for asking this again because I remember seeing that you had posted an answer to the question I am about to ask somewhere else but I can't find it.. In the general case of using the API outside browsers, or even in browsers, how does one solve the race condition that happens after creation of the object and before installing the onIncomgStream callback and the arrival of the first incoming stream? Are they queued ? 

I also think there are issues around efficiency of signaling. If the JS is going to add several local stream, if you do offer / answer after each stream is added, you end up with a pretty bad delay for overall setup time. Traditionally we have wanted some way to signal a bunch at a time. One way my be adding multiple at once or a way for the JS to indicate that they were all added and signally should start.

Received on Tuesday, 12 July 2011 14:53:04 UTC