element-hq
js-sdk voip architecture: MatrixRTCSessionManager
Your use case
https://github.com/matrix-org/matrix-js-sdk/pull/3663 introduces the MatrixRTCSessionManager. Daniel asks: does this class need to exist or could it be split between Room and MatrixcRTCSession?
Full comment:
I'm not confident that we really need the rtc session manager at this point, I'd rather invested more on the rtc session itself. IMHO currently it's fairly complicated (for the amount of code that it contains it has a high accidental complexity) and feels somewhat brittle (my gut feeling is that there will be bugs and edge-cases with the changes introduced in the PR and the solutions for them won't be particularly elegant - e.g. the solution for the async/await function looks quite complicated atm and hard to understand and it's generally not a very idiomatic way of solving state access/synchronisation problems). I also think that the API surface of the matrix RTC session could resemble LiveKit's Room a bit more (conceptually it's the same thing and it would also help unifying/merging them once we work on a deeper integration to introduce cascading). I'm particularly picky on such topics because I think that the matrix RTC session is a foundation upon which the rest of the things are going to be built in the future. That being said, if the changes are considered temporary and we don't plan to build much stuff on top of that, it might be fine to leave it like this.
We'd like to revisit this architecture later and see if the design could be better without this class (eg. maybe when we introduce support for user sessions or when implementing MatrixRTC in the rust SDK.
Have you considered any alternatives?
No response
Additional context
No response
This feels like something we have more confidence in talking about now? What's the status @element-hq/element-call-reviewers ?
@Half-Shot Thanks for raising this again. The session manager itself has not yet been challenged. Since its only job is to observe rooms and find the once that have a running session there probably will not be anything built ontop of it. In the rust sdk this is very tightly integrated with the room state. The room state has a property if there is a running session. I do like this concept since it turned out to be very little code and we already have a manager for observing changes in the room list. So maybe there is a way to
- make this class obsolete and use the session class as a joined session.
- The ongoing sessions (which require just a simple condition check on the room state events) would be handled by the roomList
- As soon as the user want to join a session we create the actual session object
What we are currently investigating is refactoring the session itself. The plan is to make it more modular and split the main tasks into seperate classes:
- A Encryption manager receiving, storing and sending keys
- A LocalMembershipManager sending state events, updating the state, sending delayed events and updating the delayed events (+ dealing with all possible error cases: rate limiting, delay timeouts, failed delayed events...)
