Closed Bug 857894 Opened 10 years ago Closed 10 years ago

Rename readyState attribute on PeerConnection object to signalingState

Categories

(Core :: WebRTC, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: jsmith, Assigned: abr)

References

Details

(Whiteboard: [WebRTC][blocking-webrtc-][spec-issue])

Chrome just renamed readyState to signalingState per the WebRTC spec. We should do the same here.
Whiteboard: [WebRTC][blocking-webrtc-]
Whiteboard: [WebRTC][blocking-webrtc-] → [WebRTC][blocking-webrtc-][spec-issue]
Duplicate of this bug: 855304
Duplicate of this bug: 831756
Assignee: nobody → adam
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.
(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...
(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.
Depends on: 859432
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.
(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.
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.
(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?
(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.
+1 from me as well
No longer depends on: 859432
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
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.