Make the js-sdk compatible with MSC preferred foci and active focus.

[toger5]

The call.member events are refactored in a backwards compatible way to not only have one array: foci_active: Focus[] but instead one array:
foci_preferred: Focus[]
and a single:
focus_active: Focus

Foci active should just be one field describing what you are currently using. In a fully cascading world this is your own foci. In the livekit scenario this describes how you connect to the correct livekit session. (using the oldest session member should be the default, but if someone is using sth else everyone should connect to the other livekit session as well. Not yet implemented)

foci_preferred is what foci_active has been. The list of possible foci this user knows about or can use.

fixes element-hq/element-call#1737

Signed-off-by: Timo K [email protected]

Checklist

• Tests written for new code (and old code if feasible).
• New or updated public/exported symbols have accurate TSDoc documentation.
• Linter and other CI checks pass.
• Sign-off given on the changes (see CONTRIBUTING.md).

[dbkr]

Sorry, I'm a bit lost here. This looks like way more than a refactor, this looks like a fundamental format change and trying to be backwards comapt. The description seems to suggest the only change is adding foci_preferred?

[AndrewFerr]

Partial review

[AndrewFerr]

Some optional requests, but this looks good overall!

[dbkr]

I think there's a typo in the PR description where you've said foci_active [] where you mean focus_active? This makes it quite a confusing read. ;)

Other than that, I think it looks plausible, although having all this to support both systems at once is heart rending. This might be more an MSC comment but what's the reason for needing to change foci_active to focus_active rather than leave it as an array?

[dbkr]

oh, also - I still vote to fix the title: 'refactor' to me means, "cleaner code with same functionality" which this isn't. In fact, documenting the reasons for changing in general would be a good thing.

[toger5]

@dbkr I updated the description and the title. Thanks.

focus_active rather than leave it as an array

An array forces us to specify how to deal with active elements of different types. This is either very complicated and/or has to be done on a per focus type bases. (It is not clear what use-cases this will have an how it will be used/ how we define how to interpret an array of active_foci. It could be to transition between infrastructure types or to have redundancy. In both cases all participants need to sync and map streams in both systems -> we need to expose this somehow outside the infrastructure itself... This all becomes more complicated than what we want matrixRTC to be.)
If there really is a use-case there will be specific custom active focus types that allow lists of foci and contain the necessary information how they are meant to be used. This also guarantees that everybody in the meeting is compatible with this custom focus type and knows how to deal with multiple active foci.)

support both systems at once is heart rending

in this case it was easy enough and we are able to merge this into the js sdk without making breaking everything.
We basically want to make the transition less stressful for us so we dont have to get it working in a couple of days now since it is broken.

This way we can merge this and work on the reliable memberships with one aspect less to worry about since the js sdk will work with both formats.

[fkwp]

lgtm