Add a ByteWriter wrapper that implements AsyncWrite for a Sink<Message>

[joshtriplett]

This is useful for programs that want to treat a WebSocket as a stream
of bytes.

---

Additional bits that could be added in future PRs:

• Implementing the tokio version of AsyncWrite if tokio is enabled
• ByteReader to implement AsyncRead for a Stream<Item = Message>

[joshtriplett]

Also, as a design note: this is built around Sink<Message> because that way it works with SplitSink in addition to WebSocketStream. It'd be quite doable to work directly on WebSocketStream, but then it won't work on SplitSink.

If you want ByteWriter to work without Sink support, it may make sense for WebSocketStream to have native split support. Open to designing this however you would prefer.

[sdroege]

If you want ByteWriter to work without Sink support, it may make sense for WebSocketStream to have native split support. Open to designing this however you would prefer.

How would such a native split() support for WebSocketStream look like though? There's not really a replacement for Sink, or is there nowadays?

Implementing the tokio version of AsyncWrite if tokio is enabled

That seems easy to add here directly. Can you do that?

[joshtriplett]

If you want ByteWriter to work without Sink support, it may make sense for WebSocketStream to have native split support. Open to designing this however you would prefer.

How would such a native split() support for WebSocketStream look like though? There's not really a replacement for Sink, or is there nowadays?

Something along the lines of WebSocketStream::split() returning a WebSocketSender that has the send function, and a WebSocketReceiver that implements Stream.

I think I can make this implementation forward-compatible with being able to do that.

Implementing the tokio version of AsyncWrite if tokio is enabled

That seems easy to add here directly. Can you do that?

Sure; just wanted to review the basic design with you first.

[sdroege]

Something along the lines of WebSocketStream::split() returning a WebSocketSender that has the send function, and a WebSocketReceiver that implements Stream.

Sounds like a good plan to me. And WebSocketSender would implement Sink if the feature is enabled, and in the future whatever new trait comes up as a replacement for Sink.

[joshtriplett]

Something along the lines of WebSocketStream::split() returning a WebSocketSender that has the send function, and a WebSocketReceiver that implements Stream.

Sounds like a good plan to me. And WebSocketSender would implement Sink if the feature is enabled, and in the future whatever new trait comes up as a replacement for Sink.

Right. And if the sink feature is enabled, ByteWriter supports any Sink, otherwise it only supports WebSocketSender and WebSocketStream.

[joshtriplett]

OK, I've added a commit implementing tokio::io::AsyncWrite. I think this is ready to merge.

As far as I can tell, this design is forward-compatible with supporting WebSocketSender in the future.

[sdroege]

Looks good to me. You'd do the AsyncRead / split() part in another PR soonish, or should I take a look at adding that in the next days? I wouldn't want to make a release with only one half :)

[joshtriplett]

@sdroege I'm working on AsyncRead now (will be a separate PR).

Less confident in adding a native split; we'll see how that goes.

(Aside: Having to write Poll-based trait implementations is draining; I really hope we get native versions someday that use async fn.)