str0m VS Protocol-Examples

In the video, Mo talked about a few packages like Cidre and StrOm, and we referred to SpaceDrive.

- Dropbox [3] uses a similar approach but they talk about it a bit more abstractly.

Sans-IO is more documented in Python [4], but str0m [5] and quinn-proto [6] are the best examples in Rust I’m aware of. Note that sans-IO is orthogonal to deterministic test frameworks, but it composes well with them.

With the disclaimer that my opinions are mine and mine alone, and don’t reflect the company I work at —— I do work at a rust shop that has utilized these techniques on some projects.

TigerBeetle is an amazing example and I’ve looked at it before! They are really the best example of this approach outside of FoundationDB I think.

[0]: https://risingwave.com/blog/deterministic-simulation-a-new-e...

[1]: https://risingwave.com/blog/applying-deterministic-simulatio...

[2]: https://dropbox.tech/infrastructure/-testing-our-new-sync-en...

[3]: https://github.com/spacejam/sled

[4]: https://fractalideas.com/blog/sans-io-when-rubber-meets-road...

[5]: https://github.com/algesten/str0m

[6]: https://docs.rs/quinn-proto/0.10.6/quinn_proto/struct.Connec...

I am really excited about https://github.com/sepfy/libpeer. It has examples ready for ESP32 etc....

When working on KVS I wasn't familiar with the embedded space at all. I saw 'heavyweight' embedded where you were running on Linux. Then you had RTOS/No OS at all. I wasn't prepared for these devices at all. If we can make WebRTC work in the embedded space I think it will really accelerate what developers are able to build!

Remotely driven cars, security cameras, robots in hospitals that bring iPads to infectious patients etc... Creative people are building amazing things. The WebRTC/video space needs to work harder and support them :)

-----

I love how diverse the WebRTC space is now. Outside of this implementation you have plenty of other options!

* https://github.com/shinyoshiaki/werift-webrtc (Typescript)

* https://github.com/pion/webrtc (Golang)

* https://github.com/webrtc-rs/webrtc (Rust)

* https://github.com/algesten/str0m (Rust)

* hhttps://github.com/sepfy/libpeer (C/Embedded)

* https://webrtc.googlesource.com/src/ (C++)

* https://github.com/sipsorcery-org/sipsorcery (C#)

* https://github.com/paullouisageneau/libdatachannel (C++)

* https://github.com/elixir-webrtc (Elixir)

* https://github.com/aiortc/aiortc (Python)

* GStreamer’s webrtcbin (C)

See https://github.com/sipsorcery/webrtc-echoes for examples of some running against each other.

Find it here: crates.io/crates/str0m Code here: github.com/algesten/str0m Docs here: docs.rs/str0m/0.1.0/str0m/

Git: https://github.com/algesten/str0m

Exactly - that's what we've already built for web development at https://replay.io :)

I did a "Learn with Jason" show discussion that covered the concepts of Replay, how to use it, and how it works:

- https://www.learnwithjason.dev/travel-through-time-to-debug-...

Not only is the debugger itself time-traveling, but those time-travel capabilities are exposed by our backend API:

- https://static.replay.io/protocol/

Our entire debugging frontend is built on that API. We've also started to build new advanced features that leverage that API in unique ways, like our React and Redux DevTools integration and "Jump to Code" feature:

- https://blog.replay.io/how-we-rebuilt-react-devtools-with-re...

- https://blog.isquaredsoftware.com/2023/10/presentations-reac...

- https://github.com/Replayio/Protocol-Examples

Not _quite_ what you're describing, but Replay [0], the company I work for, _is_ building a true "time-traveling debugger" for JS. It works by recording the OS-level interactions with the browser process, then re-running those in the cloud. From the user's perspective in our debugging client UI, they can jump to any point in a timeline and do typical step debugging. However, you can also see how many times any line of code ran, and also add print statements to any line that will print out the results from _every time that line got executed_.

So, no heap analysis per se, but you can definitely inspect the variables and stack from anywhere in the recording.

Right now our debugging client is just scratching the surface of the info we have available from our backend. We recently put together a couple small examples that use the Replay backend API to extract data from recordings and do other analysis, like generating code coverage reports and introspecting React's internals to determine whether a given component was mounting or re-rendering.

Given that capability, we hope to add the ability to do "React component stack" debugging in the not-too-distant future, such as a button that would let you "Step Back to Parent Component". We're also working on adding Redux DevTools integration now (like, I filed an initial PR for this today! [2]), and hope to add integration with other frameworks down the road.

[0] https://replay.io

[1] https://github.com/RecordReplay/replay-protocol-examples

[2] https://github.com/RecordReplay/devtools/pull/6601