Comments (9)
I'm having trouble just grokking the 6 (!) type parameters here... Perhaps this could be implemented externally first, see if it gains traction, and then maybe move in?
from tokio-io.
Yeah, it's definitely hard to read. I'm not sure how to make that easier. The basic idea is just that you're reading again and again into a user-provided buffer and passing a reference to the data read into a closure which can handle the data appropriately, either performing some side-effect or producing a Future of some data.
from tokio-io.
I'd be happy to spin it into a gist/PR/its own crate if you think that would make the intent clearer. I don't think many people would download a crate just for this function, both because of overhead and because of the difficulty of discovering the functionality.
The goal is just to provide an alternative of sorts to Decoder
that handles the incoming bytes in a buffer directly, rather than spinning it out into a Bytes
.
from tokio-io.
I agree that discoverability is a problem yeah but it's not really tenable for us to just add every combinator we can think of to tokio-io? I feel like we'd just need some threshold for inclusion beyond "a PR was sent" although I'm not quite sure what precisely such a threshold would be...
from tokio-io.
it's not really tenable for us to just add every combinator we can think of to tokio-io
Yeah, I totally get that. I see io::repeating_read(read, [0; 1024], process_buf)
as equivalent to read.framed(Bytes).map(process_buf)
, but it allows the users to provide their own buffer and so avoids the unnecessary buffer heap allocation. If that's behavior we want to encourage, then I think repeating_read
should be included. If the opinion is that these intermediate allocations don't matter enough to merit the additional method and ergonomics cost, then I'm happy to close this, as I agree that it's better to provide a single way to do things where possible. However, if we want to encourage zero-alloc parsing of the incoming buffer, then tokio-io needs something like repeating_read
.
from tokio-io.
I've written a prototype implementation of this here (FWIW there are only 4 type parameters 😄).
from tokio-io.
Ah so this is sort of where the Decoder
and Encoder
style traits are intended for "easy mode" in terms of being a good entry point but not a one-size-fits-all solution. I think most of the time we try to make it go further in terms of "one size fits all" then it becomes very difficult to work with, so we opted to just have an "easy, but not always production ready" mode and then leave other abstractions up to users
from tokio-io.
Yes, tokio-io shouldn't include all possible permutations. It is totally fine to move helpers to external crates.
from tokio-io.
Closing this was leaning towards "won't merge" and there has been no followup discussion. Please open a new issue if you want to continue this discussion.
from tokio-io.
Related Issues (20)
- Shutdown doesn't handle `Async::NotReady` HOT 5
- ReadHalf and WriteHalf don't honor underlying T's specialization
- Doc links are broken
- build is broken with bytes 0.4.7
- Add a way to override `decode_head` in `length_delimited::{FramedRead, FramedWrite}`
- Does it make sense that tokio::codec::Decoder's decode method takes a BytesMut? HOT 3
- Clean shutdown of TCP sockets HOT 4
- Add a "Bytes" Codec Implementation HOT 1
- Decoder::decode is slow for large buffers HOT 4
- Rename `AsyncWrite::shutdown` HOT 3
- Bump iovec and bytes versions
- Consider Removing the `io::Read` and `io::Write` supertraits on AsyncRead and AsyncWrite HOT 5
- Publish new version HOT 3
- Clarify behaviour of flush on WouldBlock error HOT 2
- FramedRead updates unusably slowly HOT 2
- 'lines_decoder' fails on 32-bit
- FreeBSD clients able to freeze a Tokio+Hyper Linux server HOT 9
- Reconsider including `length_delimited` in the tokio-io crate HOT 1
- LinesCodec repeatedly returns final line when line is not terminated with \n
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tokio-io.