search

security-union / videocall-rs

teleconference system written in rust
https://www.videocall.rs
MIT License
1.36k stars 117 forks source link

Factor underlying client-side engine out of yew app, for use in other clients #74

Open ronen opened 1 year ago

ronen commented 1 year ago

I'd like to embed a zoom-rs client in an existing web / electron app, written in javascript using a non-yew UI framework. That would mean decoupling the encoding/decoding code and control mechanisms from the yew UI code, factoring them out to create an "engine" that could be used in other contexts. (Something like this would be needed also for https://github.com/security-union/zoom-rs/pull/49#issuecomment-1587789179 which suggests using electron on MacOS.)

I'm imagining another top-level directory client-engine/ that would hold that code. It would be set it up so that it would both:

The engine code wouldn't require specific HTML and wouldn't create any HTML. It would just provide a control API for establishing connections etc, it would take ids of the canvas elements to render into, and it would use callbacks to communicate interesting events back to the app.

My approach would be to first factor out the client engine code but keep it within yew-ui/src/-- and once that looks good, snip it out and move it into that other directory and set up the cargo & npm mechanisms. The factoring could be done incrementally with PRs along the way, allowing reviews/suggestions as it goes and avoiding a massive shock to the code.

What do you think? I'm happy to take this on.

darioalessandro commented 1 year ago

Hey @ronen !!

I do like this because I am almost sure that by mixing render code and model we are missing on:

  1. performance.
  2. cleaner architecture (MVVM?)

My only request is to do this change incrementally so that PRs are small and decrease the chances of conflicts

ronen commented 1 year ago

Cool! I've already started working on this :)

I'll see what I can do about making small PRs -- but I want to be sure it works before taking the code down a path that may not prove fruitful. Hopefully something coming up soon.

ronen commented 1 year ago

I'll see what I can do about making small PRs -- but I want to be sure it works before taking the code down a path that may not prove fruitful. Hopefully something coming up soon.

Well, even though I don't have the whole thing done yet, seeing #83 go by made me realize you're right, I better PR what I can while I can :) So #85 is an initial step.

ronen commented 1 year ago

90 was waiting in the wings for #85 to be ready :)

ronen commented 1 year ago

Hi guys -- here's another commit waiting in the wings:

022476c "Factor out web media connection and use into model::connection::Connection"

I haven't made a PR yet since that commit is based on the commits of #96 and a PR would include all those commits too. Once #96 is merged I'll rebase against main and create a PR with just the new commit. Just showing it to you now in case you want a sneak peak / give feedback ahead of the PR.

ronen commented 1 year ago

H guys, FYI once #137 is merged, here's what I'm thinking my next steps are:

  1. Pull out the things in yew-ui/src/model into a top-level videocall-client directory. That directory would define a crate with a library that provides:

    • VideoCallClient
    • MicrophoneEncoder, CameraEncoder, ScreenEncoder
    • MediaDeviceAccess

    And change yew-ui to use that crate.

  2. Get that new videocall-client crate to compile into a wasm npm module that could be imported into javascript apps.

  3. Make another top-level directory, with an electron app that uses that npm module (and runs on MacOS :) It'd do roughly the same thing as the yew-UI app.

And once all that is working, I'd say it'd be a good time to re-visit the whole API.

What do you think?