<div dir="ltr">Guess not.<div>Personally, I the method 2 among my suggestion before is the most consistent and generic API design in this sense - streaming chunks in inflating too.</div><div>Actually, zlib.erl is implemented in streaming chunks from a port driver to the calling process.  The problem is that the calling process collects all the chunks indefinitely and there is no way to intervene.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 24, 2014 at 5:09 PM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm a little bit puzzled here.<br>
According to zlib.h, the underlying C code works with<br>
input and output buffers.  Decompression is done in<br>
chunks, and one reason for a chunk stopping is that the<br>
output buffer has filled up.  I would expect a zlib<br>
interface to say "give me the decompressed information<br>
in chunks no bigger than this, as and when I ask for them".<br>
<br>
Looking at RFC 1950 and RFC 1951, since reflecting on the fact<br>
that you are supposed to be able to create zlib compressed<br>
stuff by streaming blocks through the library without<br>
announcing the total size in advance, it really doesn't look<br>
as though there can be a way to get the size without<br>
actually decompressing.<br>
<br>
Is there any possibility of adjusting the overall protocol to<br>
transmit the size in advance?<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Park, Sungjin<div>-------------------------------------------------------------------------------------------------------------------</div><div>Peculiar travel suggestions are dancing lessons from god.</div><div>  -- The Books of Bokonon</div><div>-------------------------------------------------------------------------------------------------------------------</div>
</div>