857894 - Rename readyState attribute on PeerConnection object to signalingState

Status: RESOLVED INVALID

(Core :: WebRTC, defect)

Description

[Jason Smith [:jsmith]]

Chrome just renamed readyState to signalingState per the WebRTC spec. We should do the same here.

Comment 3

[Suhas]

It is not just the rename though. SingalingState has different values per spec than the readyState. I think we should reflect that in the bug as well.

Comment 4

[Adam Roach [:abr]]

(In reply to Suhas from comment #3)
> It is not just the rename though. SingalingState has different values per
> spec than the readyState. I think we should reflect that in the bug as well.

Yeah, that's part of why I grabbed the bug -- I wanted to make sure that the behavior was fully researched before it was implemented. I didn't know off the top of my head whether an attribute rename would do it and wanted to double-check...

Comment 5

[Jason Smith [:jsmith]]

(In reply to Adam Roach [:abr] from comment #4)
> (In reply to Suhas from comment #3)
> > It is not just the rename though. SingalingState has different values per
> > spec than the readyState. I think we should reflect that in the bug as well.
> 
> Yeah, that's part of why I grabbed the bug -- I wanted to make sure that the
> behavior was fully researched before it was implemented. I didn't know off
> the top of my head whether an attribute rename would do it and wanted to
> double-check...

Right. I filed bug 859432 about that as well.

Comment 6

[Suhas]

Probably we should leave the readyState as it is for now and implement signalingState on the peer connection and hook it back into sipcc.

readyState seems to go out of spec sooner or later for PeerConnection.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Suhas from comment #6)
> Probably we should leave the readyState as it is for now and implement
> signalingState on the peer connection and hook it back into sipcc.
> 
> readyState seems to go out of spec sooner or later for PeerConnection.

Or we just pull out the readyState attribute now to get alignment in spec and just implement the signalingState support.

Comment 8

[Suhas]

Sadly, readyState is spread out in the spec still today and there might be implementations that depend on them. Probably we should get out a mail to W3C on removing the readyState for the PeerConnection. Also to note the readyState is still well defined for DataChannel though.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Suhas from comment #8)
> Sadly, readyState is spread out in the spec still today and there might be
> implementations that depend on them. Probably we should get out a mail to
> W3C on removing the readyState for the PeerConnection. Also to note the
> readyState is still well defined for DataChannel though.

Hmm...maybe the right thing to do here then is:

1. Implement signalingState independent of readyState for now (first bug)
2. Start the W3C Discussion for pulling readyState out of PC spec
3. File a bug for tracking removal of readyState
4. Close this bug out as invalid for now by it's original definition

Does that work?

Comment 10

[Adam Roach [:abr]]

(In reply to Jason Smith [:jsmith] from comment #9)
> (In reply to Suhas from comment #8)
> > Sadly, readyState is spread out in the spec still today and there might be
> > implementations that depend on them. Probably we should get out a mail to
> > W3C on removing the readyState for the PeerConnection. Also to note the
> > readyState is still well defined for DataChannel though.
> 
> Hmm...maybe the right thing to do here then is:
> 
> 1. Implement signalingState independent of readyState for now (first bug)
> 2. Start the W3C Discussion for pulling readyState out of PC spec
> 3. File a bug for tracking removal of readyState
> 4. Close this bug out as invalid for now by it's original definition
> 
> Does that work?

I like it.

Comment 11

[Suhas]

+1 from me as well

Comment 12

[Jason Smith [:jsmith]]

I'm closing this bug as invalid along with bug 859432 and opening new bugs respectively for:

1. Creation of the signalingState attribute
2. Removal of the readyState attribute if the working group agrees