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
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
