Closed stackinspector closed 2 years ago
tokio-tungstenite
does expose a similar method though ;)
BTW consider adding a feature to the handshake related parts of crate tungstenite to support removing them in the complied product? (I know maybe I'm already asking a bit too much)
If I'm understanding it correctly, you mean extracting the basic WebSocket functionality outside of the crate (and/or making it available in a separate loosely coupled module in tungstenite
), so that other crates could rely on it? If that's what you meant, then I agree that it would be useful. In fact, we had some internal discussions with @jxs that it would be indeed not that bad to have some sort of a tungstenite-core
that provides stream-agnostic API to deal with WebSockets. That would also be very beneficial for tokio-tungstenite
, since currently we have a kludge for the requirement of tungstenite
of Stream
be Read + Write
(which Tokio's AsyncRead + AsyncWrite
are not directly compatible with).
Sorry for not carefully checking the API indeed. The provided API fits my demand perfectly.
Looking forward to seeing tungstenite-core
which will reduce a bunch of dependencies.
I wrote a simple "headless" ws/wss client/server library based on tokio-tungstenite
and tokio-rustls
, and this is what I actually need. I think it would be better if the handshake related code could be turned off with a feature. For example, for tokio-tungstenite
just including WebSocketStream
and tungstenite
re-export, and for tungstenite
not including the handshake
, client
, server
mods.
Oh, right, there is already a feature that allows to not import any handshake-related types that were recently added to tungstenite
, and there is an open request for tokio-tungstenite
here: https://github.com/snapview/tokio-tungstenite/pull/240
I think we'll just need to merge it and release both crates with the new feature.
When is the next version of this crate planned to be released?
Theoretically, we could bump a version and release a crate if someone is in need of the introduced feature (we don't have a strict release cycle, we release as soon as there are some good changes/features that are worth being released 🙂).
So do you think optional handshake worth?
We could release it, yeah, why not.
Sometimes it is convenient to use WebSocket as a "dumb" protocol on top of TCP, to avoid some of the underlying TCP details. In this case, the canonical HTTP handshake can be omitted. Using
tungstenite
directly can do this by convertingTcpStream
withWebSocket::from_raw_socket
. But when I want TLS connections and asynchronous processing, I found that this crate doesn't expose a method likefrom_raw_socket
. Consider implementing a similar method in this crate? If not, it seems necessary for me to create a new crate to encapsulate the "raw" WebSocket specifically. BTW consider adding a feature to the handshake related parts of cratetungstenite
to support removing them in the complied product? (I know maybe I'm already asking a bit too much)