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

Reply via email to