Congratulations on the release. I was interested in seeing how this would work as a WAI handler, and came across some questions:
* I noticed that the Method datatype is restricted to a set of specific methods. Seeing as the list of methods can be expanded[1], why was this chosen? * The CIByteString datatype provides no way of accessing directly the lower-case version of the bytestring, or of setting it. Seeing as WAI already lower-cases the headers (following your suggestion btw) it would be more efficient to only do this once. Would you consider exposing the constructor? * For simplicity at the moment, I decided to use the getRequestBody function, but it seems to be returning an empty result. Is there a known gotcha here? Overall, writing the WAI wrapper is pretty straight-forward. The main problem is that the WAI request body does not require an inversion of control approach, while the Snap version does; some usage of lazy I/O here could solve the problem, though that's obviously sub-optimal. Also, it seems a little unclear whether the writeBS et al functions store the body in memory before returning the result, though the documentation implies it. Could you provide some clarifications? Good work, Michael [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html> On Sat, May 22, 2010 at 8:25 AM, Gregory Collins <g...@gregorycollins.net>wrote: > Hello all, > > To coincide with Hac Phi 2010 > (http://www.haskell.org/haskellwiki/Hac_%CF%86), the Snap team is happy > to announce the first public release of the Snap Framework, a simple and > fast Haskell web programming server and library for unix systems. For > installation instructions, documentation, and more information, see our > website at http://snapframework.com/. > > Snap is well-documented and has a test suite with a high level of code > coverage, but it is early-stage software with still-evolving interfaces. > Snap > is therefore most likely to be of interest to early adopters and potential > contributors. > > Snap is BSD-licensed and currently only runs on Unix platforms; it has been > developed and tested on Linux and Mac OSX Snow Leopard. > > Snap Features: > > * A simple and clean monad for web programming, similar to happstack's but > simpler. > > * A *fast* HTTP server library with an optional high-concurrency backend > (using libev). > > * An XML-based templating system for generating xhtml that allows you to > bind > Haskell functionality to XML tags in your templates. > > * Some useful utilities for web handlers, including gzip compression and > fileServe. > > * Iteratee-based I/O, allowing composable streaming in O(1) space without > any > of the unpredictable consequences of lazy I/O. > > If you have questions or comments, please contact us on our mailing list > (http://mailman-mail5.webfaction.com/listinfo/snap) or in the > #snapframework channel on the freenode IRC network. > > Cheers, > G > -- > Gregory Collins <g...@gregorycollins.net> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe