W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2013

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 18 Jun 2013 06:49:09 -0700
Message-ID: <CABcZeBPxXWyKxGcy3NVXvyFFr6eD0jJHnoJ9DR9xPmBBarj_kg@mail.gmail.com>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
Cc: Adam Roach <adam@nostrum.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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

> 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.

Received on Tuesday, 18 June 2013 13:50:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:44 UTC