4206909 - adding Z_SYNC_FLUSH support to deflaters

[Xueming Shen]

David M. Lloyd wrote:
> On 09/10/2009 01:47 PM, Xueming Shen wrote:
>> I think we have enough discussion on this topic, it's time to make a 
>> final decision. Seems like we are all happy on the
>> changes in Deflater and new DOS.flush(mode), the only difference is 
>> whether or not we should change the existing
>> behavior of DOS.flush() should use Z_SYNC_FLUSH by default.
>
> The question is, is there really such code out there?  It can't really 
> have any useful semantics that I can see.  My irrelevant vote is 
> firmly on "yes" for this.
>
> - DML
-The question is, is there really such code out there?

I honestly don't know, this is why it is called "compatibility risk", 
similar to the investment risk in the stock market, you
lose or gain only after you put the real money in:-) Though my feeling 
is it is very "likely" this change is going to break
someone's code given DOS is designed/implemented to be easily used as a 
"normal" OutputStream.

-It can't really have any useful semantics that I can see

DOS abstracts two functionalities, a deflater and an output stream, both 
the deflater and output stream have their own
"flush" semantics. A flush on the deflater changes the final output, 
degrades the compression, basically it changes the
"function" of the deflater. A flush on the OutputStream however is 
supposed to push out the "buffered" output (accumulated
for whatever reason, mostly for the i/o performance), it does not change 
the final result/output. So arguably it should not be
a too bad idea to also provide two types of "flush" to flush the 
deflater and/or to flush the output stream, the existing
DOS.flush() "accidentally" provides the semantics of the outputstream's 
flush(), with the help of the newly added flush(mode),
now the developer have the choice of doing whatever "flush" they want to do.

Agree it's arguable that if the stream type of flush is really needed 
for DOS in real world, we can debate what should be
the default behavior (the most useful scenario) of the DOS.flush() , if 
we are designing/implementing a new DOS class. The
question we need to answer now is should we change the existing default 
behavior of DOS.flush(), all existing/running/working
application that uses DOS today is based on (happy with) the 
assumption/expectation that it does a "outputstream flush", it
does not change the final compression output. So while we fix the 
problem of "can't not flush the deflater of the DOS", do we
have to or say is it worthing to break the expectation of all existing 
users. Some time even a "byte" difference of the output result
is a BIG deal.

Every vote counts:-)

sherman