lemunozm
ws can not receive text
hi,thanks for your work! i love this crate,it help me lot! i find the ws server side can not receive text?i have check the source code. because the trait Remote's function "fn receive(&self,process_data: impl FnMut(&[u8])) -> ReadStatus". u can check it on adapter.rs i change the ws.rs, add some code for receive funciton.like this: Message::Text(text) => { drop(state); process_data(text.as_bytes()) } but this is bad way. i know if change the trait Remote will make many change do u have any good idea for ws support text?
Hi @reison1218 , I'm glad you like it!
Because we need a "common" interface for all adapters, WS works in binary mode. Nevertheless, once https://github.com/lemunozm/message-io/issues/54 was merged (thanks to @kgraefe), I think this capability for WS can be allowed through configuration. Something like:
let conn = handler.network().connect_with(TransportConnect::Ws(WsMode::Text), addr)?;
The interface of the adapter will be the same, but the &[u8] parameters can now be interpreted internally as text, and internally the Ws adapter will send/receive the data as text.
thanks for your reply. i have check the #54 so,if merge it. we can code like this?
handler.network().listen(Transport::Ws(WsMode::Message), "0.0.0.0:3044").unwrap();
why the WsMode is Message?because user can process Text and Binary both.not just one of them.
does it possible?
Respecting the current interface, you need to choose between one of them when creating the connection, because send()/recv() methods only knows about the buffer. You do not have enough information to know how to interpret what that buffer has
Given another thought on this, maybe we could have another send_with() and recv_with() that allows to pass specific transport properties, following the structure found un #54 i.e:
send_with(data, TransportProp::Ws(WsMode::Text))
Is there currently a way to receive and send text-messages or is it still work in progress?
There is no way to send text messages right now. I'm still open to review a PR with the required changes or discussing an idea. But I'm no longer adding new features in message-io, at least by now.
OK - thanks for the info.
So converting bin to text and vice versa should do as a temp. workaround. This is something every end-user should be able to do.
If the server can interpret the binary message correctly, then that can be a workaround, yes
It sends and receives unicode perfectly. So I see no problem even not at the server's side. Assumed, the server does not await plain text messages :-/