[Haskell-cafe] ANNOUNCE: zlib and bzlib 0.5 releases

[Duncan Coutts]

On Sun, 2008-11-02 at 19:07 +0300, Bulat Ziganshin wrote:
> Hello Duncan,
> 
> Sunday, November 2, 2008, 6:46:00 PM, you wrote:
> 
> > People have also asked for a continuation style api to give more control
> > over dynamic behaviour like flushing the compression state (eg in a http
> > server). Unfortunately this does not look easy.
> 
> can you gove more details on these? may be i can help

For details talk to Johan Tibell <johan.tibell at gmail.com>

Suppose you're trying to work with a strict block IO strategy, like one
of these iterator style designs. What kind of api would one want to work
with that?

The constraint is that for a pure api, the zlib compression state must
be used in a single threaded, non-persistent style.

Additionally it would be nice to expose the zlib flush feature. This is
tricky in a straightforward design because it involves a branching
structure of possible operations, and we cannot split the zlib
compression state (at least not cheaply).

If we could do it persistently we could have something like:

data StreamState = OutputAvailable
                     ByteString     -- the output buffer
                     StreamState    -- next state
                 | InputRequired
                      (ByteString -> StreamState) -- supply input
                                                  -- or
                      (Flush      -> StreamState) -- flush
                 | StreamEnd CheckSum
data Flush = FlushEnd
           | FlushSync
           | FlushFull

initialState :: StreamState

But obviously we cannot do this because we have to guarantee the single
threaded use of the stream state.

Duncan