Re: Operations in invalid states: Exceptions don't make sense.

On 24/06/2013 8:47 AM, Adam Bergkvist wrote:
> On 2013-06-24 13:44, Jim Barnett wrote:
>> Yes, but are you going to signal an error if the developer makes a
>> call when you're in a processing state?  In that case, you'll end up
>> with a lot of polling code, sitting  around waiting for the state to
>> change.  That's an ugly programming model.  Now if it's the case that
>> some operations can succeed when you're in the processing state, then
>> that's a good argument for having a processing state, since  it now
>> behaves like a first-class state, with a differentiated response to
>> different events.  But if all operations are going to fail until the
>> processing is done, the queuing model is cleaner.
>>
>
> Yes, an API call in the wrong state should result in a state error. 
> Regarding polling the state, we already got state verification with 
> the queuing model; the difference is that it's done async (for some 
> operations). It's usually not a problem since this kind of state is 
> mostly based on application context. For example, the PeerConnection 
> will be in a processing state after a call to setLocalDescription() 
> and until the success or error callback fires.
>
> Code that uses the success and error callbacks will look the same. 
> It's only questionable code like (Jan-Ivar's example):
>
>     // Bad code. state=have_local_offer
>     pc.setRemoteDescription(answer1, success, mayfail);
>     pc.setRemoteDescription(answer2, success, mayfail);
>
> that will behave differently. The second call will *always* throw an 
> exception because the PeerConnection is in a processing state as a 
> result of the first call. With a queue, the behavior is derived from 
> rules that depends on what happens to the first call.
>
> The processing states are real states. You can do anything beside call 
> some the sensitive operations we currently queue.
>
> /Adam
>

     Adam, you're wrong to assume that users won't receive multiple 
events in parallel. Why? Because events can come from two sources:

  * The PeerConnection
  * The server (used during the bootstrap process)

For example:

  * PeerConnection is processing a command, createAnswer(), updateIce(),
    etc.
  * The remote peer disconnects or sends an ICE candidate, requiring me
    to invoke PeerConnection.close() or addIceCandidate()

I'm already been forced to implement an application-level queue in the 
opposite direction because the server may return HTTP 503 at any time, 
requiring me to sleep and repeat the operation. This means that when 
PeerConnection fires an event I cannot simply send it to the server: I 
have to queue it and send it at a later time.

Gili