[rs] Add streams-quic example

[zh4ngx]

Implement stream-quic-{client, server} based on streams-nats-{client, server} and hello-quic-{client, server}.

Should the handling of multiple invocation streams follow the approach in hello-quic-server or stream-nats-server?

@rvolosatovs

[rvolosatovs]

Should the handling of multiple invocation streams follow the approach in hello-quic-server or stream-nats-server?

they seem to be identical other that the QUIC version having to abort accepts on shutdown, could you elaborate?

[zh4ngx]

Should the handling of multiple invocation streams follow the approach in hello-quic-server or stream-nats-server?

they seem to be identical other that the QUIC version having to abort accepts on shutdown, could you elaborate?

Sure, I think it might be around more general questions:

• What is the role of the task collection here, and why does it not appear in the nats example?
• Why is there no srv.accept(...) step in stream-nats-server like there is in hello-quic-server?
• How does bindings::serve(...) work? In hello-quic-server it takes a wrpc_transport_quic::Server, but in stream-nats-server it takes in a wrpc_transport_nats::Client.

Thanks!

[rvolosatovs]

Should the handling of multiple invocation streams follow the approach in hello-quic-server or stream-nats-server?

they seem to be identical other that the QUIC version having to abort accepts on shutdown, could you elaborate?

Sure, I think it might be around more general questions:

* What is the role of the task collection [here](https://github.com/bytecodealliance/wrpc/blob/main/examples/rust/hello-quic-server/src/main.rs#L74-L112), and why does it not appear in the nats example?

* Why is there no `srv.accept(...)` step in `stream-nats-server` like there is in [`hello-quic-server`](https://github.com/bytecodealliance/wrpc/blob/main/examples/rust/hello-quic-server/src/main.rs#L89)?

* How does `bindings::serve(...)` work? In [`hello-quic-server`](https://github.com/bytecodealliance/wrpc/blob/main/examples/rust/hello-quic-server/src/main.rs#L114) it takes a `wrpc_transport_quic::Server`, but in [`stream-nats-server`](https://github.com/bytecodealliance/wrpc/blob/main/examples/rust/streams-nats-server/src/main.rs#L69) it takes in a `wrpc_transport_nats::Client`.

Thanks!

In case of NATS.io there is a single connection to the NATS broker and "accepting" is done behind the scenes by async-nats crate and framing is handled by the NATS protocol, whereas in case of QUIC, we have to perform the accept ourselves, handle framing and pass the accepted connection to wRPC.

This is all quite low-level and we should definitely introduce a higher-level abstraction with opinionated defaults for developers who don't necessarily require this high degree of control

[zh4ngx]

Should the handling of multiple invocation streams follow the approach in hello-quic-server or stream-nats-server?

they seem to be identical other that the QUIC version having to abort accepts on shutdown, could you elaborate?

Sure, I think it might be around more general questions:

* What is the role of the task collection [here](https://github.com/bytecodealliance/wrpc/blob/main/examples/rust/hello-quic-server/src/main.rs#L74-L112), and why does it not appear in the nats example?

* Why is there no `srv.accept(...)` step in `stream-nats-server` like there is in [`hello-quic-server`](https://github.com/bytecodealliance/wrpc/blob/main/examples/rust/hello-quic-server/src/main.rs#L89)?

* How does `bindings::serve(...)` work? In [`hello-quic-server`](https://github.com/bytecodealliance/wrpc/blob/main/examples/rust/hello-quic-server/src/main.rs#L114) it takes a `wrpc_transport_quic::Server`, but in [`stream-nats-server`](https://github.com/bytecodealliance/wrpc/blob/main/examples/rust/streams-nats-server/src/main.rs#L69) it takes in a `wrpc_transport_nats::Client`.

Thanks!

In case of NATS.io there is a single connection to the NATS broker and "accepting" is done behind the scenes by async-nats crate and framing is handled by the NATS protocol, whereas in case of QUIC, we have to perform the accept ourselves, handle framing and pass the accepted connection to wRPC.

This is all quite low-level and we should definitely introduce a higher-level abstraction with opinionated defaults for developers who don't necessarily require this high degree of control

Got it - thanks for the explanation. Yes, that sounds like a good idea. Would be happy to help with that as I get more familiar with the internals.