In a multithreaded wasm app, do all threads have equal access to the DOM, or is it more like JS where there is a UI thread which can access all APIs and a bunch of worker threads which can only access a more limited set of APIs?
If the latter, has anyone sought to expose that constraint to the Rust type system? e.g. via a capabilities object that's neither Sync nor Send
In other words, we tried hard to document a lot of before-the-fact rationalizations to go with the inevitable after-the-fact rationalizations. :-)
I don't think it matters what the Daily team originally intended. It is exciting/inspiring to me that they are trying to solve things differently. I think security for RTC is really important, so seeing more memory safe language usage makes me hopeful for the future.
All this new code also means people are really learning what goes into these problems. A whole new generation of coders are getting into the space and rethinking things. It is great.
it seems like these reasons to do something mysteriously only stay valid for the short period of time in which a technology has some kind of hype status and quickly fades when people realize that it's actually not that much improvement in practice and the hassles (training devs in new language, worse language ecosystem etc.) aren't actually worth it.
Have you evaluated webrtc-rs yet? I haven't keep up to date with mediasoup, but I saw they have a rust effort. Have you evaluated that yet?
Seems possible to drop lots of C++ dependencies :)
Regarding mediasoup, their Rust effort so far has focused mostly on the server side of things, whereas for this particular project we would be looking more towards the client side.
That would definitely be something we are considering contributing to, as it would, as you say, drop quite a significant amount of C++ (with additional benefits on the web side, too).
The server side is the hard part to work on. Also, one of the downsides of wasm is that it can be a pain to communicate out to the JS APIs, especially for doing lots of DOM manipulation. I'm not sure how sound this approach is really. It seems like you're going to do a lot of extra work in order to solve a problem that isn't much of a problem in the first place.
`daily-core` is signaling, the (always evolving) low-level trickery needed to scale calls to 10,000+ participants, state management, and an opinionated internal API that lets us efficiently maintain public-facing API features like track management, and device selection.
Edit: Also, webrtc-rs doesn't work for me either; AFAIK, it doesn't yet have enough of the media stack, including hard stuff like echo cancellation.
Vincent here, fellow dev at Daily, working on daily-core and Daily for iOS. :)
We did evaluate webrtc-rs, but we found that it simply isn't yet were it would need to be in order to be a realistic replacement for libwebrtc.a today. As a matter of fact I am a member of the webrtc-rs org (https://github.com/orgs/webrtc-rs/people), having contributed the audio-buffer and constraint-algorithm implementations so far (https://news.ycombinator.com/item?id=31000261).
I personally have high hopes for being able to make the jump at some point. Just alone being able to toss the monstrous `build.rs` that currently ties ninja/gn (libwebrtc), cmake (libmediasoupclient), clang (our own bridging code) and bindgen (for header imports) together and makes things work across multiple platforms would almost be worth it for me. With Rust implementations of mediasoupclient and webrtc none of this hassle would be necessary. In pure Rust stuff just works.
