You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on an async networking service that will need to emit metrics, soon. After looking at the existing crates available, dogstatsd is one of my top choices. Unfortunately for me, none of the existing crates support async/await. But fortunately for you, I will be able to dedicate some company time to implement this.
Before I begin any work or submit any PRs, I'd like to start a conversation to work out the details. Has there been any brainstorming on what the API might look like, or are there any immediate plans to begin work on async/await? Would you be happy with a feature gate to transform the public API into an async interface, or would you prefer a separate collection of structs? Or maybe even a separate crate altogether?
The code as-is seems like it would lend itself pretty nicely to the former; a feature gate. One challenge I can spot right away is that the Client struct assumes it will be responsible for creating the socket (tightly coupling it with the socket impl in std). This is easy to change to a type that is generic over anything that implements Read + Write (or AsyncRead + AsyncWrite).
This work will probably fall on my plate in early January. Let me know if you are interested in collaborating, and what (if anything) may have already been done.
The text was updated successfully, but these errors were encountered:
I'm working on an async networking service that will need to emit metrics, soon. After looking at the existing crates available,
dogstatsd
is one of my top choices. Unfortunately for me, none of the existing crates support async/await. But fortunately for you, I will be able to dedicate some company time to implement this.Before I begin any work or submit any PRs, I'd like to start a conversation to work out the details. Has there been any brainstorming on what the API might look like, or are there any immediate plans to begin work on async/await? Would you be happy with a feature gate to transform the public API into an async interface, or would you prefer a separate collection of structs? Or maybe even a separate crate altogether?
The code as-is seems like it would lend itself pretty nicely to the former; a feature gate. One challenge I can spot right away is that the
Client
struct assumes it will be responsible for creating the socket (tightly coupling it with the socket impl in std). This is easy to change to a type that is generic over anything that implementsRead + Write
(orAsyncRead + AsyncWrite
).This work will probably fall on my plate in early January. Let me know if you are interested in collaborating, and what (if anything) may have already been done.
The text was updated successfully, but these errors were encountered: