What's the state of WASM support?

[simbleau]

The library seems to have no examples, tests, or a README. Is this a side project or a serious attempt at supporting WASM client webtransport in Bevy?

To add, I'm interested in seeing where this goes. I'm an author of Matchbox (WebRTC) and bevy_rtc, but I'm in the market lately for a simpler network layer. WebRTC is becoming difficult to manage.

[MOZGIII]

WASM support is more serious than ever with my recent work on #129 which implements hard-crafted bindings to the WebTransport Web API.
There are some blockers on the wasm_bindgen side, but the bindings we get are much more suitable than the ones that web-sys generated are, they even work quite well as a semi-high-level way for writing WebTransport code in my experiments. Although that in only for the new experimental stuff - the presently released stuff is working quite well.

Also, while there are indeed no examples or readme as of now - there are tests. They are designed in such a way that we implement them once and test all the supported drivers, so both native and wasm are known to work.

Another thing to note is the API currently in not stable, and I'll likely be changing the crates structure (specifically what does into the main xwt crate) in the near future. The drivers and xwt-core are quite relatively stable, but I want a more explicit and user-firendly API at the xwt carte itself. Stay tuned for that.

Regarding the status of the project - it is a side project, but I am quite serious about it, as it is being used by a lot of people, including myself, in production even.

The examples and proper docs are lacking due to the plans to change the xwt interface, and those being de-facto more important things for the core dev like myself to spend the time on. PRs are welcome though.

Oh, and yeah, it is already being used in my own project with bevy, as well as a couple of crates that build on top of xwt-web-sys. I have a limited time I can spend on this, otherwise there would be more bindings to the higher-level crates, specifically for bevy.

WebRTC is extremely complicated, WebTransport is much easier in this regard. They're even working on the P2P spec for it, which is super cool. Great job on Matchbox btw, I considered using it for my project before deciding on WebTransport!

[MOZGIII]

To elaborate more on the current state:

• we have some tests, maybe not as much and comprehensive as I'd like - but the tests so far we not a priority target, but rather a minimal solution to maintain some quality level, as people have already started using it and finding bugs
• we have solid CI and testing system - this I did already implement properly, and while the test themselves are not so great just yet - it is (or should at least be) easy to add more
• we have core traits and drivers that are quite stable and flexible
• we currently build with the "open internals" in mind, not hiding the dependencies API to enable end-users to work around any encountered issues easily; the driver crates are backend-specific, so there will likely never be a need to hide the internals with this design

[simbleau]

Is there an example of a bevy project using this, that works on WASM? Would it be much to ask for a minimum example, like bevy_rtc does?

If it's stable enough I can make the switch, I will. Just trying to detect blockers.

In general, im wanting to see or make a "bevy_xwt", with an exact and equivalent API to bevy_rtc. Bevy_rtc uses a server/client topology over WebRTC provided by matchbox, and hides all of the WebRTC skill gap from users, clicks into Bevy system parameters and the ecosystem, and it supports web/native.

At a high level, bevy_rtc is a crate with a client and server feature (plugins), provides a "Protocol" derive macro to allow a struct to be sent/receieved, and two system parameters, RtcClient and RtcServer for reading and writing to eachother unreliable or reliable.

[MOZGIII]

This is great, as xwt does not try to provide a high-level networking protocol on top of WebTransport, and there already a lot of crates that do - so is little need for xwt to go that route.
This means that implementation on top of xwt are welcome, but they'd have to use their own branding and etc.

One this though - I'd like to reserve the bevy_xwt crate name to provide an official component that runs xwt together with bevy - i.e. without hiding the xwt internals but exposing them. That way all other higher-level networking crates can integrate with xwt in bevy without implementing the common runtime bits - only their own specifics; this is something that emerged as a use-case in the wild, so you might to to actually do that as well.

At a high level, bevy_rtc is a crate with a client and server feature (plugins), provides a "Protocol" derive macro to allow a struct to be sent/receieved, and two system parameters, RtcClient and RtcServer for reading and writing to eachother unreliable or reliable.

It sounds like the RtcClient and RtcServer could be generics implemented by both WebRTC and WebTransport - so maybe just provide support for that? xwt-core is actually perfect for it. Can be added to the bevy_rtc without even having a new crate.

[simbleau]

This is great, as xwt does not try to provide a high-level networking protocol on top of WebTransport, and there already a lot of crates that do - so is little need for xwt to go that route. This means that implementation on top of xwt are welcome, but they'd have to use their own branding and etc.

One this though - I'd like to reserve the bevy_xwt crate name to provide an official component that runs xwt together with bevy - i.e. without hiding the xwt internals but exposing them. That way all other higher-level networking crates can integrate with xwt in bevy without implementing the common runtime bits - only their own specifics; this is something that emerged as a use-case in the wild, so you might to to actually do that as well.

At a high level, bevy_rtc is a crate with a client and server feature (plugins), provides a "Protocol" derive macro to allow a struct to be sent/receieved, and two system parameters, RtcClient and RtcServer for reading and writing to eachother unreliable or reliable.

It sounds like the RtcClient and RtcServer could be generics implemented by both WebRTC and WebTransport - so maybe just provide support for that? xwt-core is actually perfect for it. Can be added to the bevy_rtc without even having a new crate.

I'll take a look at xwt and xwt-core, and see if I can retrofit webtransport into bevy_rtc as an experiment. Thanks :)

[MOZGIII]

I added examples