[erlang-questions] zlib design flaw?

[Park, Sungjin]

Thank you Robert.
It's so common that has the cool name!


On Wed, Sep 24, 2014 at 5:26 PM, Park, Sungjin <jinni.park@REDACTED> wrote:

> 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
>
> -------------------------------------------------------------------------------------------------------------------
>



-- 
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/eda90285/attachment.htm>