Removing interface use for RTCSessionDescription and RTCIceCandidate

[martinthomson]

We currently force people to do this:

var x = new {moz|webkit|prefix}RTCIceCandidate(stuff_I_got_from_signaling);
pc.addCandidate(x);

This is nicer:

pc.addCandidate(stuff_I_got_from_signaling);

Same for session descriptions.

[dontcallmedom]

Is it safe to remove the constructors? I was under the impression they were used in quite a bit of developer documentation, and thus presumably in actual deployed code.

[martinthomson]

Yes, the constructors are used by every piece of code that uses WebRTC because they are needed in the current API. We would, as a matter of practice, retain the constructors for a significant amount of time to avoid breaking things.

[dontcallmedom]

Shouldn't there be some text indicating that the constructors are there purely for legacy reasons?

[stefhak]

List discussion ongoing.

[stefhak]

There has been some list discussion, and no-one seem to object this change, so I think we should merge.

[martinthomson]

I just realized that there is a problem with this PR. You can't have dictionary attributes on an interface. localDescription on RTCPeerConnection won't work with this. Unless we change localDescription to be a getter, then we're required to have an interface.

[adam-be]

Good catch. That is indeed a problem.

And we have the same issue with the RTCPeerConnectionIceEvent interface and its candidate attribute.

[dontcallmedom]

Still, we could (as @jan-ivar suggested) make it possible to use the init dictionaries as arguments to addIceCandidate / set*Description.

[adam-be]

I wish we had a special "pass by value" attribute in WebIDL. Because that's what we're doing with the local/remoteDescription attributes anyway.

[martinthomson]

OK, I've updated the PR. All the setXxxDescription functions take an RTCSessionDescriptionInit argument. I've noted two aspects of deprecation on RTCSessionDescription: the constructor and the mutability.

@adam-be:

I wish we had a special "pass by value" attribute in WebIDL. Because that's what we're doing with the local/remoteDescription attributes anyway.

We could use a named getter to return a dictionary, but that would look terrible and have some unwanted side-effects. Or, we could request a change to WebIDL that allowed us to return a dictionary. Or, we could annotate as you suggest.