On 5/14/13 13:39, Martin Thomson wrote:
> On 14 May 2013 10:30, Adam Roach <adam@nostrum.com> wrote:
>> On 5/14/13 12:20, Martin Thomson wrote:
>>> On 14 May 2013 07:33, Eric Rescorla <ekr@rtfm.com> wrote:
>>>> FWIW, I my vote is that the state change at the time that the callback
>>>> fires.
>>> I agree, but you could be more precise. A state change should happen
>>> when the actions associated with set(Local|Remote)Description are
>>> complete.
>> And successful.
> I'm not sure, but I think that state transitions might be unavoidable
> as a result of certain failures.
>
Right. But that's not what I meant.
The problem with the current spec is that the state transitions are all
worded in a way that assumes success. Look at Jan-Ivar's example:
have-local-offer A local description, of type "offer", has been
supplied.
That's an extremely naïve way of describing it, since it presumes that
the SDP is valid and that the PeerConnection signaling state machine was
in a state for which supplying local offer made sense. (Alternately, on
its face, it means that the state changes to "have-local-offer"
regardless of whether the offer was valid or whether it made any sense
to supply it). So, when I said "and successful," what I really meant was
that it would be far clearer to say something like:
have-local-offer A local description, of type "offer", has been
successfully applied.
Obviously, failures can make the state transition in other ways, but
that's not what I was referring to above.
/a
Received on Tuesday, 14 May 2013 18:59:44 UTC