We have two kinds of WebRTC workers: A producer and a consumer. Currently, the caller has no control over how those workers decide to rendezvous for discovery and signaling. When you construct a worker, you're given one that uses Freddie over HTTP(S) for rendezvous, whether you like it or not.
We should stub out a rendezvous abstraction here before too much complexity builds up around us. The WebRTCOptions struct should keep a reference to a parameterizable rendezvous module which abstracts away the related logic. Rendezvous should probably be abstracted as a nested state machine.
So the worker state machine will govern the stable proxying state, disconnection detection, creating and destroying datachannel resources, etc. -- and it'll delegate to a rendezvous state machine for the discovery and signaling steps.
Currently, the WebRTCOptions struct encapsulates some data of questionable relevance to WebRTC itself, sort of blending WebRTC concepts with general configuration information. It's worth scrutinizing everything in there and separating concerns while working on this ticket.
We have two kinds of WebRTC workers: A producer and a consumer. Currently, the caller has no control over how those workers decide to rendezvous for discovery and signaling. When you construct a worker, you're given one that uses Freddie over HTTP(S) for rendezvous, whether you like it or not.
We should stub out a rendezvous abstraction here before too much complexity builds up around us. The
WebRTCOptionsstruct should keep a reference to a parameterizable rendezvous module which abstracts away the related logic. Rendezvous should probably be abstracted as a nested state machine.So the worker state machine will govern the stable proxying state, disconnection detection, creating and destroying datachannel resources, etc. -- and it'll delegate to a rendezvous state machine for the discovery and signaling steps.
Currently, the
WebRTCOptionsstruct encapsulates some data of questionable relevance to WebRTC itself, sort of blending WebRTC concepts with general configuration information. It's worth scrutinizing everything in there and separating concerns while working on this ticket.