<div dir="ltr">2014-09-24 10:26 GMT+02:00 Park, Sungjin <span dir="ltr"><<a href="mailto:jinni.park@gmail.com" target="_blank">jinni.park@gmail.com</a>></span>:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div>Of course, you could feed zlib:inflate one small chunk of the input at a time. Assuming the previously quoted bound of compression is correct, taking say 1kB chunks would limit the inflated chunk size to ~1MB. If you are really careful you can do one byte of input at a time.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div></div><div class="gmail_extra"><span class=""><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></blockquote></div></span></div></blockquote><div>I suspect that the idea is to avoid getting "partially inflated" bytes. Limiting the inflated size would require a more elaborate internal state in zlib, and also more corner cases in the API.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><span class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></span></div></blockquote><div>If the compressed data is actually zip or gzip, size information is present in the metadata. However, a malicious user can fake this, as would probably be the case with any solution transmitting the size. I guess you could create a cryptographic protocol which guarantees that the transmitted size is correct, but that may be overkill...<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><span class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div><br><br clear="all"><div><br></div></span><span class="">-- <br>Park, Sungjin<div>-------------------------------------------------------------------------------------------------------------------</div><div>Peculiar travel suggestions are dancing lessons from god.</div><div>  -- The Books of Bokonon</div><div>-------------------------------------------------------------------------------------------------------------------</div>
</span></div>
<br></blockquote><div>/Håkan Huss <br></div></div></div></div>