My suggestions for APIs

[redoriental]

I have a suggestion that the same stream should only be triggered once, and then the data transmitted through the stream will pass through OnStreamData. It is also recommended that each stream carry a streamId.

[BiagioFesta]

Hi, thank you for your feedback!
Suggestions on API is a great way to improve the project (considering I've just started to work on it), so I can have a perception about real potential usage.

I could definitely add a way to retrieve the stream ID from the "handlers". Of course, streams already carry their ID, so I would be just a matter of provide a public accessor to it.

Please consider the public interface over the streams is still lacking of some functionalities: for now, I've only added basic methods for reading and writing in order to make it operable.
The general idea behind the wtransport library is to provide a very easy-to-use API, to simplify the integration with the web in Rust. The reference I have in mind is what W3C is proposing for web implementations: https://www.w3.org/TR/webtransport/

I am not quite sure I got what you mean with:

I have a suggestion that the same stream should only be triggered once

can you please provide me with more information or maybe an example?

[redoriental]

I would like to design the API to be similar to WebSocket with "onStream" and "onDatagram" events, exposing a simple API to developers. Additionally, it seems that your receiving method does not currently support datagram-based communication.

[redoriental]

If you can further improve it, I believe your project can have a greater impact than QUIC or NEQO.

[BiagioFesta]

Additionally, it seems that your receiving method does not currently support datagram-based communication.

Starting support: #3

😄

[redoriental]

I'm glad that you are able to enable the datagram functionality, and it's already a great success that the onStream method is triggered only once for the same stream. I believe your project will become a mainstream project for webTransport in the future.