I see that zlib streams accept a callback to their write method, which will be called when the input buffer is completely read (I'm guessing). But I don't see documentation of that in the API docs. Is it safe to use this feature?
On Tue, Oct 9, 2012 at 12:42 PM, khs4473 <khs4...@gmail.com> wrote:
> I see that zlib streams accept a callback to their write method, which will
> be called when the input buffer is completely read (I'm guessing). But I
> don't see documentation of that in the API docs. Is it safe to use this
> feature?
If you add a listener on the 'data' event, or call .pause() or
.resume(), then new style streams will switch into old-style. So,
existing programs should Just Work, but there are a bunch of new
classes that you'll be able to use to extend in userland streams so
that they play nicely with everything else.
On Tue, Oct 9, 2012 at 1:09 PM, khs4473 <khs4...@gmail.com> wrote:
> Cool - are new-style streams and old-style streams going to coexist in 0.10,
> or is everything being moved over to new-style?
I'd like very much to have a way to determine when zlib is done with a buffer, but without using the callback it appears to be a black hole of sorts for whatever I put in.
I'm all for allocating like mad and using the GC to manage things, but I would also like to have the option of micro-managing buffers if I choose. It's systems programming, right? : )
On Tue, Oct 9, 2012 at 6:52 PM, khs4473 <khs4...@gmail.com> wrote:
> Hmmm...
> I'd like very much to have a way to determine when zlib is done with a
> buffer, but without using the callback it appears to be a black hole of
> sorts for whatever I put in.
> I'm all for allocating like mad and using the GC to manage things, but I
> would also like to have the option of micro-managing buffers if I choose.
> It's systems programming, right? : )
I could be misguided, but I find that I gravitate toward low-level IO, like the interface that fs provides. The cool thing about fs (not the streams, but the posix functions), is that I can wrap them in whatever abstraction makes sense at the time. I can create my own stream classes around it, or I can make it callback-based or promise-based if I prefer. At the lowest level, it's pure simplicity:
read: fill this buffer with this many bytes, please, and call this function when yer done (and let me know how much you wrote).
write: write this many bytes from this buffer and let me know when you're done with said buffer.
> On Tue, Oct 9, 2012 at 6:52 PM, khs4473 <khs4...@gmail.com> wrote:
>> Hmmm...
>> I'd like very much to have a way to determine when zlib is done with a
>> buffer, but without using the callback it appears to be a black hole of
>> sorts for whatever I put in.
>> I'm all for allocating like mad and using the GC to manage things, but I
>> would also like to have the option of micro-managing buffers if I choose.
>> It's systems programming, right? : )
> > On Tue, Oct 9, 2012 at 6:52 PM, khs4473 <khs4...@gmail.com<javascript:;>>
> wrote:
> >> Hmmm...
> >> I'd like very much to have a way to determine when zlib is done with a
> >> buffer, but without using the callback it appears to be a black hole of
> >> sorts for whatever I put in.
> >> I'm all for allocating like mad and using the GC to manage things, but I
> >> would also like to have the option of micro-managing buffers if I
> choose.
> >> It's systems programming, right? : )
