Closed walfie closed 7 years ago
Well, I think writing codecs is perfectly fine. They have quite a bit of boilerplate, but not hard to write either.
But if you make a pull request, and it doesn't look very invasive I don't mind applying it. The only issue is that I don't want to release a backward-incompatible release without a good reason, so this issue might lay around until we need another breaking change.
Ah, ok. I'll take a look to see if I can find a nice way to do it with a codec first. I'll close this issue for now, and reopen later if necessary.
I'm trying to use
BufferedDispatcher::new_with_websockets
to handle HTTP and websocket requests on the server side. It works great, however I have a lot of cases where I need to send the same thing to multiple websocket sinks (e.g., broadcast the same message to all users).I couldn't find a good way to do this without having to clone the data for every user, since everything accepts a
Packet
, which owns its data in aVec<u8>
orString
(although encoding a Packet only requires a reference to the bytes).Is there a recommended way to do this without cloning?
On a related note, I'm guessing the reason
Packet
is usingString
/Vec
is so that it's compatible with futures/tokio, which requires'static
in most places. However ifPacket
were defined as:it would allow
Packet
to still "own" the data, and allow end-users to use something like the bytes crate to share the data internally (or define their ownArc<Vec<u8>>
wrapper that can dereference to an array of bytes, etc). This would probably make the API more annoying to use though, for what might be an uncommon use case.I could try implementing a
Codec
in my own code, but since most of the logic is the same, it looks like I would have to copy/paste a lot of the private stuff fromBufferedCodec
andwebsocket::ServerCodec
/websocket::zero_copy
.