search

haxetink / tink_streams

Streams from the future. With lasers, of course ... whoaaaaa!!!!
The Unlicense
12 stars 9 forks source link

Simplify #24

Open back2dos opened 3 years ago

back2dos commented 3 years ago

This is still missing quite a few things (implicit casts and regrouping), but it vastly improves performance for synchronous streams and fixes #20 in the process.

It also makes stream iteration consistently lazy and suspendable.

Which brings me to my main question: what to do with blending? I don't fully understand the use case. It introduces a temporal component that can only be conserved if the blended stream is eager. The only usage I found was tink_websocket, to blend in the pongs in the TcpConnector, but I wonder if there are others.

kevinresol commented 3 years ago

The only usage I found was tink_websocket

That's the only case I remember using it too. It was for automatically chipping in ping-pong messages to keep the connection alive. I guess we can just remove it and let high-level code handle these.

kevinresol commented 3 years ago

How about let us merge this and deal with downstream usage later?

back2dos commented 3 years ago

Actually, tink_io seems quite deeply affected by this. Need to resolve at least #27 to move forward.

kevinresol commented 3 years ago

About websocket blend stream, the idea was that the incoming stream which can contain both signalling messages (ping/pong) and user messages is split into two streams respectively. For the signalling stream it is supposed to be handled internally by the framework i.e. auto ping pong. While the user message stream is passed to developer.

In this particular use case, the blended stream is actually eager because it is eagerly consumed and piped into the wire.

I guess we can live without blended stream, by simply consuming the two streams individually?