On 10/24/17 5:32 AM, Martin Nowak wrote:
On Monday, 23 October 2017 at 16:34:19 UTC, Steven Schveighoffer wrote:
On 10/21/17 6:33 AM, Martin Nowak wrote:
It's solving a different problem than iopipe is solving. I plan on
adding iopipe-on-range capability soon as well, since many times, all
you have is a range.
On 10/19/2017 03:12 PM, Steven Schveighoffer wrote:
On 10/19/17 7:13 AM, Martin Nowak wrote:
On 10/13/2017 08:39 PM, Steven Schveighoffer wrote:
You mean chunk based processing vs. infinite lookahead for parsing?
They both provide a similar API, sth. to extend the current window and
sth. to release data.
The example input here was an input range, but it's read in page sizes
and could as well be a socket.
iopipe provides "infinite" lookahead, which is central to its purpose.
The trouble with bolting that on top of ranges, as you said, is that we
have to copy everything out of the range, which necessarily buffers
somehow (if it's efficient i/o), so you are double buffering. iopipe's
purpose is to get rid of this unnecessary buffering. This is why it's a
great fit for being the *base* of a range.
In other words, if you want something to have optional lookahead and
range support, it's better to start out with an extendable buffering
type like an iopipe, and bolt ranges on top, vs. the other way around.