-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for tokio-tungstenite
.
#129
Comments
What do you think about switching serenity and songbird to |
That should be fine, and means we don't need to worry about all the conditional config that would come up if we supported two backends. While I'm not sure what the exact library differences are, this seems reasonable versus supporting many backends if serenity makes the switch. |
It's mostly just |
Check for the required changes in serenity |
This places songbird, serenity, and twilight onto the same WS library, hopefully reducing the compile overhead for everyone. Tested using `cargo make ready` and by running `examples/voice`. Closes serenity-rs#129.
This places songbird, serenity, and twilight onto the same WS library, hopefully reducing the compile overhead for everyone. Tested using `cargo make ready` and by running `examples/voice`. Closes #129.
This places songbird, serenity, and twilight onto the same WS library, hopefully reducing the compile overhead for everyone. Tested using `cargo make ready` and by running `examples/voice`. Closes #129.
This places songbird, serenity, and twilight onto the same WS library, hopefully reducing the compile overhead for everyone. Tested using `cargo make ready` and by running `examples/voice`. Closes serenity-rs#129.
This will prevent twilight users from compiling two separate Websocket libraries. Ideally, this should be implemented as an additive feature: having features for both backends selected should add a parameter to
Config
to choose this at runtime (with an arbitrary default).The text was updated successfully, but these errors were encountered: