-
-
Notifications
You must be signed in to change notification settings - Fork 720
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
Make the websocket Message easier to work with #903
base: master
Are you sure you want to change the base?
Make the websocket Message easier to work with #903
Conversation
a9f7ee5
to
1ce802b
Compare
Rebased to fix formatting |
Hi, and thanks for your interest! There is already #821 on the pipeline |
Sorry for not doing due diligence and checking for existing pull requests. How should I proceed? Close this in favor of the existing pull request? I've noticed that there hasn't been any progress in the original pull request for several months. |
no worries! :) yeah I was just noticing that as well, and this one already addresses my review on the other and uses |
Sorry for bumping, but is there anything I could do to help get this merged? |
Currently the
Message
type is a bit hard to work with as can be seen here: https://github.com/communityvi/communityvi/blob/26bfbe16c8c4dc46545edeebf96d2b3aed8887ab/communityvi-server/src/utils/websocket_message_conversion.rs#L4-L33While looking at the code I also happened to notice the comment about
non-exhaustive
enum:warp/src/filters/ws.rs
Lines 267 to 274 in 9e74ff9
It would of course be best for usability/interoperability if warp used
tungstenite::protocol::Message
directly. I assume the opaqueMessage
type was introduced to allow for changes in the underlying implementation, without breaking warp's API?This pull request contains 2 commits:
Message
into anon-exhaustive
enum without breaking the existing APIFrom
fortungstenite::protocol::Message
in both directions. This doesn't break the API, but it exposes the respective version of thetungstenite::protocol::Message
, making any future update of thetungstenite
dependency a potentially breaking change. If that is undesired, I can remove this second commit.