Brotli,Deflate,GZIP closes stream too early. about easycompressor HOT 8 CLOSED

Most stream API have an option for leave open, which would be a good approach imho.

from easycompressor.

Interesting point. 
Let me examine the problem.

from easycompressor.

We have 4 approaches to solve this problem.

1- Adding leaveOutputStreamOpen parameter to Compress methods since Compress methods currentlty dispose only the output stream. (which passed to Encoder/Compressor stream like LZ4Stream.Encode(outputStream) )
And adding leaveInputStreamOpen parameters to Decompress methods since Decompress methods currently dispose only the input stream. (which passed to Decoder/Decompressor stream like LZ4Stream.Decode(inputStream) )

2- Adding an option (like LeaveOpenSettings) that has two property (leaveOutputStreamOpen and leaveInputStreamOpen) to Compress and Decompress methods to determine which input/output streams must be disposed after operation completes.

3- And Adding just one leaveOpen parameter to both Compress and Decompress methods to leave open both input and output streams if it is true and dispose them manually if it is false.
Note: In this way, we have breaking changes because these methods dispose both streams (something that has not been done before) if it is false (By default, the leaveOpen parameter will be false)

Note: All three approaches above will require method signature changes and for CompressAsync and DecompressAsync that has CancellationToken as the third parameter currently (instead of leaveOpen) cause breaking changes but we can fix this problem by adding two extension methods to ICompressor that gives CancellationToken as the third parameter and pass the default value (false) to leaveOpen at the method call to main Compress/Decompress methods.

4- No adding any parameter to Compress and Decompress methods. Just pass leaveOpen: true to underlying Encoder/Decoder streams to prevent from disposing input and output streams. (like LZ4Stream.Encode(outputStream, leaveOpen: true))
Note: In with way, unlike previous approaches we have not any method signature changes.
But we have a minimum breaking changes because Compress/Decompress methods no longer dispose any streams (something that has not been done before).

IMO, approach 4 is better choice because require no method signature changes and also disposing the streams is not related to Compress/Decompress methods and it is not their jobs.

Now, what do you think? I would like to know your opinion.

from easycompressor.

Currently, this test (that checks streams are not closed after Compress/Decompress completes) is passed regard to approach 4 (passing leaveOpen: true to underlying Encoder/Decoder streams without adding any parameters to Compress/Decompress methods)

from easycompressor.

I think approach four is suitable as it would usually be surrounded by a stream with an using statement.

from easycompressor.

I also agree.
Version 1.4.0 was released in order to fix this issue.

from easycompressor.

@mjebrahimi thanks for fixing the issue :)

from easycompressor.

@jetersen thank you for the report and contribution.

from easycompressor.