A few weeks ago, I wrote a blog post about a proposal for WAI 3.0, which would no longer be based on conduit, and therefore be open to various streaming data frameworks. The response I've received so far has been (I think universally) positive, and therefore I'd like to move forward. There was a good discussion on Reddit[1], but I think the mailing list is a better way to come to consensus on a last few points. In particular, there are two questions still up in the air: 1. Twan raised the question[2] of how to deal with the streaming response body. We need the ability to either emit a new Builder, or flush the stream. I believe we have three different interfaces available to choose from: a. (Maybe Builder -> IO ()) -> IO () b. (Builder -> IO ()) -> IO () -> IO () c. data ResponseStream = ResponseStream { responseStreamPart :: Builder -> IO () , responseStreamFlush :: IO () } ResponseStream -> IO () (a) is probably the simplest, but also likely to be the least efficient. I tend towards choosing (b), since it avoids the need for an extra datatype, but (c) looks cleaner overall. 2. Dan[3] and Stephen[4] both raised issues about how we'd deal with scarce resource allocation when creating a streaming response. Here's a summary: a. The approach I linked to in the blog came down to the bracket pattern. The downsides of this are (i) a poorly behaving application could call the callback multiple times, and (ii) it complicates the interface. b. To avoid problem (i), we could use something like the Acquire datatype[5], making the type signature `type Application = Request -> Acquire Response`. I'm overall negative on this, as the goal here is to continue simplifying to standard datatypes. c. Stephen's suggestion is to include a cleanup action in the ResponseStream constructor. My primary concern here is that it will be very difficult for application authors to write async-exception-safe code, vs option (a) which makes it trivial. On both of these questions, new ideas are certainly welcome. Michael [1] http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_guttin... [2] http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_guttin... [3] http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_guttin... [4] http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_guttin... [5] http://hackage.haskell.org/package/resourcet-1.1.2/docs/Data-Acquire.html