W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2014

Re: renaming updateIce

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Wed, 30 Apr 2014 10:43:15 -0400
Message-ID: <53610C03.6050800@mozilla.com>
To: public-webrtc@w3.org
On 4/30/14 4:37 AM, cowwoc wrote:
> On 30/04/2014 4:22 AM, Adam Bergkvist wrote:
>> On 2014-04-30 07:26, Justin Uberti wrote:
>>> Since RTCConfiguration is no longer solely about ICE, and we now have
>>> PeerConnection.getConfiguration(), I propose that
>>> PeerConnection.updateIce() be renamed to
>>> PeerConnection.updateConfiguration(), or perhaps even
>>> PeerConnection.setConfiguration().
>>>
>>> Any objections to this change?
>>
>> I support this.

+1. I too vote for setConfiguration, just because 'Update' means so many 
different things (I've never met an update method there wasn't something 
wrong with).

At the same time, we should probably clarify whether setConfiguration({ 
}) clears out all settings or does nothing. I think the former would be 
most consistent with our other dictionary use (applyConstraint).

>>
>> /Adam
>>
>
> I think setConfiguration(RTCConfiguration) is preferable in the sense 
> that you don't want to end up with PeerConnection.getConfiguration() 
> returning a value that doesn't actually correspond to the current 
> PeerConnection state.
>
> If you use the Builder design pattern, you could do even better:
>
>   PeerConnection.getConfiguration().changeSomething().apply()
>
> where PeerConnection.getConfiguration() returns a copy-on-write 
> configuration object and apply() updates the PeerConnection, otherwise 
> the object is discarded and never used.

Dictionaries already address the telescoping constructor problem, so 
while I'm a fan of the builder pattern, it seems redundant here.

.: Jan-Ivar :.

> Gili
Received on Wednesday, 30 April 2014 14:43:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:38 UTC