Closed bitfl0wer closed 9 months ago
Ideally, these abstractions/adapters would be written in a way which requires the minimum amount of conditional compiling flags/macro invocations.
Also, huge thanks to @hw0lff for aiding me through the entire way of figuring out what exactly caused the dependency inclusions which made chorus not compile for wasm32-unknown. Likely would have rage-quit if it weren't for his help :)
Currently, Chorus relies on
tokio_tungstenite
and itsWebSocketStream
. This blocks Chorus from being compiled forwasm32-unknown-unknown
, becausetokio_tungstenite
, in this context, uses aMaybeTlsStream
(which uses either openssl/nativetls or rustls, all of which are not compatible with this compilation target) andtokio
snet
feature as a dependency (also unavailable forwasm32-unknown
).A possible solution here would be to use
web_sys::WebSocket
, which leverages Web APIs to have your browser (or whatever executor you have) handle the TLS/SSL stuff for us. This is, as far as I can tell, the only/current best way to use TLS Websockets for this compilation target. To do this, we'd have to do what the title says and make bothGateway
andGatewayHandle
and theirwebsocket_send
andwebsocket_receive
fields generic over theStream
andSink
types provided byfutures_util
. This way, we can feature-lock wasm-compatibility, we do not have to replace our existing reliance on tokio-tungstenite and we do not have to change the control flow ingateway.rs
in major ways.