signalingOptions

[thegobot]

No description provided.

[jianjunz]

The ctor of ConferenceClient accepts a signaling channel object, which allows custom configuration or even implementation for signaling.

owt-client-javascript/src/sdk/conference/client.js

Line 122 in aa407d6

export const ConferenceClient = function(config, signalingImpl) {

[thegobot]

The ctor of ConferenceClient accepts a signaling channel object, which allows custom configuration or even implementation for signaling.

owt-client-javascript/src/sdk/conference/client.js

Line 122 in aa407d6

export const ConferenceClient = function(config, signalingImpl) {

I understand, but why should I make my own implementation if I need to change 1 parameter (path)? I use nginx to proxy

[jianjunz]

The signaling options may not work for all signaling implementations. It may conflict with signalingImpl in ConferenceClient. Consider two cases here:

1. Another new signaling protocol is added, e.g.: WebTransport. The signalingOptions may apply to a specific signaling protocol only.
2. A user provided signaling module, which could also based on socket.io, doesn't support this option, so it could potentially be ignored.

If I understand correctly, the value of signalingOptions applies to a specific signaling implementation. It's better to be an argument of the signaling implementation's ctor. Then use this signaling implementation to create a ConferenceClient.

[thegobot]

The signaling options may not work for all signaling implementations

The end user must know (and choose in advance) the implementation. Options he applies to a known implementation, obviously

[jianjunz]

The signaling implementation could be undefined, SDK choses one. It's socket.io at this time, but it could be another one in the future. There is no guarantee that undefined signaling implementation is always the socket.io one.