Conversation
you can either wrap a |
Yeah, but I'm annoyed because I want a Looking around I see another lib: EDIT: I want to clarify, I do like the Iterator approach to generating chunks, which means I want to stay on the side of |
|
Since the actual bugfix was covered elsewhere, but the refactor is still useful alone, I opened #21 to specifically address this refactor. |
Inspired by / stolen from PR #1 Not called ChunkIterator because a more specific "chunk iterator" will be created next for converting text into chunk string content (base64 incl. prefix)
Does not do base64 yet
Assume readable text string is the input (likely base64-encoded binary) instead of random binary to base64 encode ourselves
Was hardcoded to 10, now done properly. We calculate it as naive total / readsize, rather than including the overhead in calculation, which would lead to counterintuitive results: When reading N bytes from a 2N stream, you expect 2 read operations, not 3 (overhead of chunk prefix = 8 bytes per chunk)
b560776 to
b5c7621
Compare
YAML optional dep was never used in master, only experimented with.
Using feedback from PR #24 to make this code better.
"Panic message not a string litteral" solved now
New (unused) iterators for simplifying encoding,
BufferedIterator wraps the
read N bytesissue fine (based on PR #1), and ChunkIterator supposed to return a full chunk string onnext(). This works, but thebase64is not integrated yet.Unit Tests are RED on the ChunkIterator, due to comparing byte array to string.
Open question is how to integrate base64 conversion inside the process, when the base64::EncoderWriter approach is a
Writertrait, not aReadertrait, so I can't make a oneliner pipeline cleanly, it seems.