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

On Tue, Jun 18, 2013 at 6:15 AM, Adam Bergkvist <adam.bergkvist@ericsson.com
> wrote:

> On 2013-05-22 09:31, Adam Roach wrote:
>
>> Currently, the WebRTC spec has some implication that a PeerConnection's
>> signalingState should be checked at the time an operation (e.g.,
>> setRemoteDescription) is enqueued, and an that an exception should be
>> thrown if the state is not appropriate for the indicated operation /at
>> that time//,/ regardless of how the already-enqueued operations may
>>
>> change that state.
>>
>> This is covered in section 4.6.1 (Error Handling / General Principles):
>> " An exception /MUST/ be thrown... [if a] function call was made when
>>
>> the RTCPeerConnection is in an invalid state, or a state in which that
>> particular function is not allowed to be executed."
>>
>> This interacts badly with the conceptual model that we currently have
>> around operations, which is that scripts are allowed to make several
>> calls on the PeerConnection without first waiting for the prior one to
>> complete (with the result being that the PeerConnection queues such
>> operations until the previous one completes).
>>
>>
> I'm currently editing the spec based on the discussion in this thread but
> everything isn't really clear to me.
>
> It makes sense to only allow one operation that affects or is dependent on
> the PeerConnection's signaling state at a time, but can you provide an
> example where it's useful to queue up several calls on a PeerConnection
> without waiting for the success callback of the previous call? It's a high
> risk that such code is error prone.


Given that the calls are asynchronous, I don't see how we can stop people.



> It also involves a lot of state checking on the thread that processes the
> queued operations which is not the JS thread (unless I misunderstood).
>

That has to happen anyway. In fact, it's that that this API is trying to
accomodate.



> Wouldn't it be simpler to have a model where the PeerConnection enters a
> "processing" state when, for example, setLocalDescription() is called, and
> the state is updated in the task that fires the methods success or error
> callback? The "single operation at a time" rule would then be enforced by
> the PeerConnection signaling state.
>

That actually sounds quite confusing.

-Ekr