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