The ZOutputStream of the "competing" jzlib has its "flush" control in
its write() method,
it invokes "defalter.deflate()" with a "flush" parameter, the
"flush"parameter is a protected
instance variable of the ZOutputStream class with a default value of
z_no_flush. So its
subclass can set whatever value is desirable. Its default "flush()" does
the same thing we do,
out.flush():-) So obviously all the "happy" jzlib users do not feel too
bad to write their own
subclass to achieve whatever they can not get from our DOS/deflater.
While I still feel my original proposal is very close what the jzlib
offers. I'm happy with
Alan's approach, and I suggest we simply do the z_no_flush/z_sync_flush.
It should
not be too difficult for sophisticated developer to write their own DOS
with the new
deflater class.
sherman
Alan Bateman wrote:
Martin Buchholz wrote:
:
The use case for full flush is partial recoverability from future
corruption
of the data. If the competing java zib libraries are supporting this
flush variant,
we probably should too, for completeness.
It's worth considering although we get into detail as to how the flush
mode is expressed in the constructor (an int is awkward because of the
existing size parameter, and java.util.zip was well into adolescence
when enums were introduced). The other option is to just ignore it as
the proposed Deflater.deflate method supports full flush and it's not
too difficult to create your own OutputStream that uses Deflater.
-Alan.
