Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type-safe ChannelPipeline #39

Open
weissi opened this issue Feb 27, 2018 · 2 comments
Open

Type-safe ChannelPipeline #39

weissi opened this issue Feb 27, 2018 · 2 comments
Assignees
Labels
kind/enhancement Improvements to existing feature.

Comments

@weissi
Copy link
Member

weissi commented Feb 27, 2018

It would be great to have a type-safe ChannelPipeline. The whole ChannelPipeline can't be all type-safe as we want to support arbitrary modifications of it at runtime (for example for HTTP/1 to HTTP/2 upgrades).
However it would be great to be able to have at least a partially type-safe pipeline which could be fully type-safe for programs who don't need the dynamism.

@weissi weissi added the kind/enhancement Improvements to existing feature. label Feb 27, 2018
@weissi weissi self-assigned this Feb 27, 2018
@weissi
Copy link
Member Author

weissi commented Feb 27, 2018

I have some partial code doing that, currently blocked on https://bugs.swift.org/browse/SR-5546

@PeterAdams-A
Copy link
Contributor

I think this is probably a clone of #1354

weissi added a commit to weissi/swift-nio that referenced this issue Feb 3, 2024
Motivation:

LineBasedFrameDecoder discarded everything after EOF and delivered it in
the left-over bytes error. For the real world however that doesn't make
much sense, you'd want all previously received lines and only receive
the partial lines as left-overs.

Modifications:

deliver lines until there are only partial lines left, even in case of
EOF.

Result:

LineBasedFrameDecoder more useful
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Improvements to existing feature.
Projects
None yet
Development

No branches or pull requests

2 participants