Improved streamable body implementation. #67
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bi-directional streaming is important for things like WebSockets, especially considering that we want to keep the WebSocket client and server as efficient as possible.
Streamable bodies use the
stream? -> true
escape hatch which reduces the complexity of supporting bi-directional streaming clients and servers.I have a strong desire to remove this feature as the complexity is only slightly outweighed by the benefits. As an interface, it's strictly worse IMHO. In essence, the streaming interface has distinctly different requirements on the client and server side (see
#stream(input)
on the client side).As an alternative, maybe we can remove "Streamable" as a concept and instead introduce some kind of
hijack!
mechanism for the request and response side of the connection handling. This mechanism only applies to HTTP/1 in general.Types of Changes
Contribution