:   '''zlib push''' ''mode channel'' ?''options ...''?
This command, part of [zlib], adds a compressing or decompressing transformation to ''channel''. The type of transformation is given by the ''mode'', which must be one of '''compress''', '''decompress''', '''deflate''', '''inflate''', '''gzip''', '''gunzip'''.

The following options may be used:
   '''-header''' ''dict'':   Define gzip header fields, using same rules as [zlib gzip]. Only used for the '''gzip''' transformation.
   '''-level''' ''level'':   Define the compression level, using same rules as [zlib compress], [zlib deflate] and [zlib gzip]. Only used for compressing transformations.

The following [fconfigure]/[chan configure] options are added:
   '''-flush''' ''type'':   This write-only option causes an immediate operation: it flushes the internal buffers of the transformation. Two types of flush are currently defined: '''sync''' flushes empty the buffers but do not make the state restartable, and '''full''' flushes empty the buffers and also make the state restartable (at greater performance penalty). For decompressing transformations, there's no difference.
   '''-checksum''' ''number'':   This read-only option returns the checksum of the uncompressed data seen so far. The algorithm used is format-dependent.
   '''-header''' ''dict'':   This read-only option returns the header dictionary (according to [zlib gunzip] rules) from a '''gunzip''' transformation.

To reverse the '''zlib push''', use [chan pop].
----
[DKF]: Be aware that the current implementation of the compressing and (especially) decompressing filters doesn't support [seek]ing. If you can help improve this, please contact the Tcl Maintainers, on mailto:tcl-core@lists.sf.net

[MAKR] 2009-05-05: I cannot think of a sensible implementation for [seek]ing in deflated data. You'd either have to buffer the inflated data, or restart inflating the block to seek to every time. The first one either blows the memory or stores the data in some cache file. The second possibility would need a buffer, too, but suffers more from performance penalty. Storing the data in some file bothers me also wrt security. I have an [zlib] [channel] implementation for [Tcl] 8.4 using the [zlib] bindings provided in [Tclkit] wrapped up with [rechan]. I was thinking a lot about how to implement seeking, but finally realized that what I want is seeking in the inflated data. Thus no seeking in the channel implementation, and I haven't missed it yet :-) ...

----
!!!!!!
%| [Category Command] | [Category Compression] | [Category Channel] |%
!!!!!!