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:
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:
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.

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.

Yes, definitely.

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.


Reply via email to