Future Enhancements / WIP / Roadmap? about message-io HOT 2 CLOSED

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] (#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] (#53) Add a reliable & ordering over UDP adapter
• Any other adapter is totally welcome.
• [easy] (#55) Improved RemoteAddr usage.
• [medium] (#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] (#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] (#60) Reduce the encoding size using variadic int encoding.
• New and fresh ideas coming from rustaceans :)

from message-io.

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

from message-io.