[Haskell-cafe] ANNOUNCE: zlib and bzlib 0.5 releases
duncan.coutts at worc.ox.ac.uk
Sun Nov 2 12:16:54 EST 2008
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
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
(ByteString -> StreamState) -- supply input
(Flush -> StreamState) -- flush
| StreamEnd CheckSum
data Flush = FlushEnd
initialState :: StreamState
But obviously we cannot do this because we have to guarantee the single
threaded use of the stream state.
More information about the Haskell-Cafe