[erlang-questions] zlib design flaw?

[Park, Sungjin]

Guess not.
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.
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.


On Wed, Sep 24, 2014 at 5:09 PM, Richard A. O'Keefe <ok@REDACTED>
wrote:

> I'm a little bit puzzled here.
> According to zlib.h, the underlying C code works with
> input and output buffers.  Decompression is done in
> chunks, and one reason for a chunk stopping is that the
> output buffer has filled up.  I would expect a zlib
> interface to say "give me the decompressed information
> in chunks no bigger than this, as and when I ask for them".
>
> Looking at RFC 1950 and RFC 1951, since reflecting on the fact
> that you are supposed to be able to create zlib compressed
> stuff by streaming blocks through the library without
> announcing the total size in advance, it really doesn't look
> as though there can be a way to get the size without
> actually decompressing.
>
> Is there any possibility of adjusting the overall protocol to
> transmit the size in advance?
>
>


-- 
Park, Sungjin
-------------------------------------------------------------------------------------------------------------------
Peculiar travel suggestions are dancing lessons from god.
  -- The Books of Bokonon
-------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140924/fe72503d/attachment.htm>