The new (net11.0) public ZLibDecoder implements and requires IDisposable - fine.
BUT: the instance method "Decompress" has a internal implementation that allows only ONE call.
Every additional call does not decompress!!
It returns status done, but bytesConsumed==0, bytesWritten==0!
This is for the internal implementation of the used DeflateDecoder.
My idea and understanding was to use the same instance of ZLibDecoder for multiple decompressions, avoiding the allocations for the ZLibDecoder instance!
This currently is not possible - i have to create and dispose the ZLibDecoder for each decompression operation.
Using the static "TryDecompression" it does exactly this (create/dispose for each call).
Proposals:
a) improve documentation (minimum)
b) provide a implementation that allows multiple calls (not sure if the lowest level Api allows this)
c) "hide" the public constructor for ZLibDecoder because it causes mistakes. The Static TryDecompress works very well.
d) make the internal "finished" state public so the user can see that the Instance is consumed (only one call working)
BR
Werner
The new (net11.0) public ZLibDecoder implements and requires IDisposable - fine.
BUT: the instance method "Decompress" has a internal implementation that allows only ONE call.
Every additional call does not decompress!!
It returns status done, but bytesConsumed==0, bytesWritten==0!
This is for the internal implementation of the used DeflateDecoder.
My idea and understanding was to use the same instance of ZLibDecoder for multiple decompressions, avoiding the allocations for the ZLibDecoder instance!
This currently is not possible - i have to create and dispose the ZLibDecoder for each decompression operation.
Using the static "TryDecompression" it does exactly this (create/dispose for each call).
Proposals:
a) improve documentation (minimum)
b) provide a implementation that allows multiple calls (not sure if the lowest level Api allows this)
c) "hide" the public constructor for ZLibDecoder because it causes mistakes. The Static TryDecompress works very well.
d) make the internal "finished" state public so the user can see that the Instance is consumed (only one call working)
BR
Werner