- From: Peter Thatcher <pthatcher@google.com>
- Date: Fri, 18 Sep 2015 15:57:24 -0700
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAJrXDUG5OvCtduOg+Lcw=4V80BzNt5bCDx9Qh5uefNha877Zig@mail.gmail.com>
Actually, I went to type A in the PR, and it was complicated. Writing the spec for B is much more simple. Perhaps that's a sign that it's a better idea than A (it's easier read and understand what it means). So I change my mind: if we don't want a new state, let's go with B. And that's what's in the PR now. On Fri, Sep 18, 2015 at 3:43 PM, Peter Thatcher <pthatcher@google.com> wrote: > And if don't want a new state, I'd recommend going with A, that it's > "new", which is the least weird, in my opinion. > > On Fri, Sep 18, 2015 at 3:40 PM, Peter Thatcher <pthatcher@google.com> > wrote: > >> Someone already tried to implement PeerConnection.connectionState: >> https://github.com/fippo/adapter/commit/ae3004a9a8efed0eee419e07a037904701679e0d >> >> While reading it, I realized we have a state in PR #291 which isn't >> covered: if there are some IceTranpsorts in the new state and other >> IceTranpsorts in the connected state. What's the aggregate state? At the >> f2f, the rules I put on the slide made it into the connected state. But >> the rules I typed in the PR leave it undefined. Currently in the PR, the >> rules are, basically: >> >> If any connecting (ignoring closed/failed/disconnected) => connecting >> If all connected (ignoring closed/failed/disconnected) => connected >> >> Which leaves it unclear what to do with some connected but non connecting. >> >> >> In other words, imagine this timeline: >> >> T0: transport1 = new; aggregate: new >> T1: transport1 = connecting; aggregate: connecting >> T1: transport1 = connected; aggregate: connected >> T2: transport1 = connected; transport2 = new; aggregate: ??? >> T3: transport1 = connecting; transport2 = connecting; aggregate: >> connecting >> T4: transport1 = connecting; transport2 = connecting; transport3 = new; >> aggregate: connecting >> T5: transport1 = connecting; transport2 = connected; transport3 = new; >> aggregate: ??? >> >> >> I think our choices are: >> >> A. aggregate at T2/T5 is new. This means that transport2 going from >> connecting to connected at T5 causes the aggregate to go from connecting to >> new, which is a little weird. This is how my slides at the f2f proposed it. >> >> B. aggregate at T2/T5 is connected. This means adding a new transport >> at T2 doesn't affect the aggregate until it goes to connecting at T3, which >> is a little weird. >> >> C. aggregate at T2/T5 is new and aggregate at T3 is also new. This >> means that a transport going to connecting doesn't affect the aggregate >> until all of the transports get past the "new" state, which means that the >> aggregate a T3 is new, even though transport2 is already connecting, which >> is a little weird. >> >> D. Add a new state. partially-connected? >> >> >> As weird as it sounds, I'm thinking D is the best option. At least it >> tells JS exactly what is going on; it's partially connected, it isn't >> connecting, it isn't failed, and it isn't disconnected. >> > >
Received on Friday, 18 September 2015 22:58:32 UTC