The main objective of this issue is to make sure that we're building all new development in this project on top of safe decoupled abstractions that could be developed and unit-tested separately from each other and allow us to gain more speed and flexibility while extending the server!
Since SFU is slowly gaining more features and must be written in a future-proof way, it makes sense to make sure that we're building the SFU on a stable basis:
[x] Enable as many links as possible.
[x] Remove circular dependencies (pointers) between structures.
[x] Confine access of objects as much as possible to each other (least privilege principle).
[x] Define clear responsibilities of different parts of the system.
[x] Remove variables that are just copies of the information available through other sources to avoid sync issues and confusion.
[x] Lower the probability of race conditions by checking the use of all mutexes and replacing some of them with message-passing workflows (i.e. the "Do not communicate by sharing memory; instead, share memory by communicating.”)
[x] Extract signaling logging in a separate file or package.
[x] Document the code so that it's clear for application developers to understand what's going on and why it's going on 🙂
@daniel-abramov:
The main objective of this issue is to make sure that we're building all new development in this project on top of safe decoupled abstractions that could be developed and unit-tested separately from each other and allow us to gain more speed and flexibility while extending the server!
Since SFU is slowly gaining more features and must be written in a future-proof way, it makes sense to make sure that we're building the SFU on a stable basis: