- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Wed, 30 Apr 2014 10:43:15 -0400
- 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