Can we rename setSelectedCandidatePair to selectCandidatePair ?

[jan-ivar]

Sorry for not catching this in review, but...

Is it too late to rename setSelectedCandidatePair to selectCandidatePair ?

Using the right verbs often helps when defining methods.

Also, "setFoo" methods are a bit of an anti-pattern I feel (they beg the question of whether something should have been a setter attribute instead.)

cc @sam-vi

[sam-vi]

setSelectedCandidatePair was proposed as a natural counterpart to RTCIceTransport.getSelectedCandidatePair.

I don't think a setter attribute is a good fit here because:

1. setSelectedCandidatePair does not immediately mutate the internal slot returned by getSelectedCandidatePair, that only happens asynchronously.
2. setSelectedCandidatePair performs a complex operation (ICE agent actions), something that the Web Platform Design Principles recommends against attributes from performing.

Thinking also about @henbos's suggestion in https://github.com/w3c/webrtc-extensions/pull/175#pullrequestreview-1701469462, perhaps an overall improvement, which also makes the verb more suitable, would be to change the method signature to

Promise<undefined> setSelectedCandidatePair(RTCIceCandidatePair candidatePair);

Then the sequence of operations on setSelectedCandidatePair is:

• Perform input & state validation
• Return a promise
• In parallel, instruct the ICE agent to change the selected candidate pair
• Upon completion, update the SelectedCandidatePair internal slot
• Fire the selectedcandidatepairchange event
• Resolve the promise

Then the application knows when the setter completes and the getter is consistent with the result. get/setParameters in RTCRtpSender have a similar structure.

The spec changes should be minimal. What do you think?

[jan-ivar]

I don't think a setter attribute is a good fit here because:

Note I'm not proposing a setter attribute.

1. setSelectedCandidatePair does not immediately mutate the internal slot returned by getSelectedCandidatePair, that only happens asynchronously.

Right, setSelectedCandidatePair seems a bad name for the same reason.

I'm proposing calling the method selectCandidatePair. This implies a method that is doing something (selecting) other than simply storing the value immediately.

Returning a promise seems orthogonal to naming, but I agree it would conveniently solve the issue of expected behavior by clarifying when the returned value should match

await transceiver.transport.iceTransport.selectCandidatePair(foo);
const bar = transceiver.transport.iceTransport.getSelectCandidatePair();
// foo and bar should match

[henbos]

Renaming this method SGTM