Future Enhancements / WIP / Roadmap?

[RobDavenport]

As I mentioned in my previous issue, I'm really enjoying this crate.

I'd like to more about what upcoming enhancements or new features are on the way, and maybe contribute where I can. What is currently in development for the near future? Would it be possible to get these listed as issues on this board for others to contribute and discuss?

[lemunozm]

Thanks again @RobDavenport. I put a big effort to clean the internals to make message-io "easy" to contribute.

As an overview (as you say, I will open some related issues):

• [unestimated] (Add a WebRTC adapter #52) Add a WebRTS adapter to complete the web support (I do not know much about this protocol and I need to learn about it before implementing an adapter, if somebody knows and wants to help, it is welcome!)
• [medium] (Add a reliable & ordering over UDP adapter #53) Add a reliable & ordering over UDP adapter
• Any other adapter is totally welcome.
• [easy] (Improve RemoteAddr usage #55) Improved RemoteAddr usage.
• [medium] (Adapter with configuration properties by connection/listening #54) Add configuration properties to the adapter.
• [difficult] A non-blocking connect() function. Currently, connect blocks until the connection is performed. It is suitable for the majority of cases, but it could be cool to offer a non-blocking version that allows reading the connect status in the event loop.
• [medium] Non-blocking write with POLLIN event. Although writing data can be considered "non-blocking" because it is rare that the OS sending buffer is full, It could happen (sender really fast and receiver really slow). In this case, currently, message-io will block the sender until the OS sends data and empty the buffer. It should be little time but has a cost. Instead, in those cases, the data could be stored and the socket registered as POLLIN to wake up later and send the data using the internal message-io thread.
• [medium/difficult] More robust and stable throughput performance tests against directly std.
• [easy] (Improving Decoder performance using Read trait. #75) Add a Reader to the Decoder.
• [unestimated] reading with balanced change. I do not know a possible fix to it but there is an issue where if a receiver is slow and a sender is really fast sending without waiting, the receiver only will read from one socket because this socket never will return a WouldBlock (I will open an issue with an extended explanation).
• [easy] (Encoding with less bytes. #60) Reduce the encoding size using variadic int encoding.
• New and fresh ideas coming from rustaceans :)

[lemunozm]

I close it since there are issues have been created with this info