iopipe alpha 0.0.1 version

[Steven Schveighoffer]

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.

-Steve