Re: [Haskell-cafe] [ANNOUNCE] First Public Release of the Snap Framework
Agreed, I think Snap just raised the bar for presentation of Haskell libraries. It even has a custom Haddock style sheet! I'm glad it is built up of separate packages. I also look forward to using it. On 22 May 2010 09:10, Chris Eidhof ch...@eidhof.nl wrote: Awesome! Congratulations on the first release, I look forward to working with it. Also, the web design is great, possibly the best designed Haskell library website I've seen so far. -chris On 22 mei 2010, at 07:25, Gregory Collins 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] First Public Release of the Snap Framework
Awesome! Congratulations on the first release, I look forward to working with it. Also, the web design is great, possibly the best designed Haskell library website I've seen so far. -chris On 22 mei 2010, at 07:25, Gregory Collins 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
Re: [Haskell-cafe] [ANNOUNCE] First Public Release of the Snap Framework
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.netwrote: 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
Re: [Haskell-cafe] [ANNOUNCE] First Public Release of the Snap Framework
Michael Snoyman mich...@snoyman.com writes: 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 answer is no particular reason -- nobody really uses this. I think you're right that this makes us technically out of spec, if it becomes an issue for anyone we'll add a custom constructor later. * 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? Would you accept: ciToLower :: CIByteString - ByteString instead? I prefer opaque datatypes in general. We didn't see a need for that use-case, the idea was that the string representation would be the same but we would do a case-insensitive compare. * 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? If the POST body has content-type application/x-www-form-urlencoded we parse it for you and put the fields in the parameter mapping. If this isn't your case I'd appreciate a bug report. This is a place where we made a different design decision than you did -- a WAI application which expects to parse the POST body itself won't work. I'll think about adding a knob to make this behaviour optional. 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. A Chan a forkIO could work here also (we've discussed that one before I think.) 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? The Snap monad carries a Response in its state, with rspBody being an output Enumerator. The writeBS function composes enumBS foo with the Enumerator from that state; so when you call writeBS you're really building up a *program* to send the response body out later. So yes, we hang onto that data until the request is served. If you want to stream in O(1) space you need to provide an Enumerator to do so; the Enumerator has access to the IO monad though. We provide writeBS/writeLBS for those situations in which it's convenient/appropriate to build up the entire response in memory. G. -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] First Public Release of the Snap Framework
On Sat, May 22, 2010 at 11:15 PM, Gregory Collins g...@gregorycollins.netwrote: Michael Snoyman mich...@snoyman.com writes: 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 answer is no particular reason -- nobody really uses this. I think you're right that this makes us technically out of spec, if it becomes an issue for anyone we'll add a custom constructor later. * 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? Would you accept: ciToLower :: CIByteString - ByteString instead? I prefer opaque datatypes in general. We didn't see a need for that use-case, the idea was that the string representation would be the same but we would do a case-insensitive compare. Well, that solves half the problem: I also would like to be able to hand in a lower-case version when converting from the WAI ResponseHeader to a CIByteString. * 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? If the POST body has content-type application/x-www-form-urlencoded we parse it for you and put the fields in the parameter mapping. If this isn't your case I'd appreciate a bug report. This is a place where we made a different design decision than you did -- a WAI application which expects to parse the POST body itself won't work. I'll think about adding a knob to make this behaviour optional. I'd appreciate such a knob. Out of curiosity, do you also parse multi-part data? 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. A Chan a forkIO could work here also (we've discussed that one before I think.) You're right; it doesn't actually require the lazy I/O bit, just the forkIO. Not that I'm crazy about that solution either. 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? The Snap monad carries a Response in its state, with rspBody being an output Enumerator. The writeBS function composes enumBS foo with the Enumerator from that state; so when you call writeBS you're really building up a *program* to send the response body out later. So yes, we hang onto that data until the request is served. That's what it looked like to me; maybe you could update the docs to make that clear. I'd hate for people to accidentally kill their performance. If you want to stream in O(1) space you need to provide an Enumerator to do so; the Enumerator has access to the IO monad though. We provide writeBS/writeLBS for those situations in which it's convenient/appropriate to build up the entire response in memory. I figured I'd end up writing that, but I just wanted to test things out the simple way first via writeLBS. I'll have to wait in any event for the ability to bypass automatic request body parsing. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] First Public Release of the Snap Framework
Michael Snoyman mich...@snoyman.com writes: Would you accept: ciToLower :: CIByteString - ByteString instead? I prefer opaque datatypes in general. We didn't see a need for that use-case, the idea was that the string representation would be the same but we would do a case-insensitive compare. Well, that solves half the problem: I also would like to be able to hand in a lower-case version when converting from the WAI ResponseHeader to a CIByteString. You can pass a lower-case input, it'll get lowercased again but that isn't such a big price to pay. If the POST body has content-type application/x-www-form-urlencoded we parse it for you and put the fields in the parameter mapping. If this isn't your case I'd appreciate a bug report. This is a place where we made a different design decision than you did -- a WAI application which expects to parse the POST body itself won't work. I'll think about adding a knob to make this behaviour optional. I'd appreciate such a knob. Out of curiosity, do you also parse multi-part data? No, not yet :(, and we'll never do so automatically; we limit POST bodies to 1MB or something like that (to prevent malicious requests from trashing the server) but multipart requests can contain file uploads, which we would probably want to be able to stream to disk somehow. G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] First Public Release of the Snap Framework
On Sun, May 23, 2010 at 1:36 AM, Gregory Collins g...@gregorycollins.netwrote: Michael Snoyman mich...@snoyman.com writes: If the POST body has content-type application/x-www-form-urlencoded we parse it for you and put the fields in the parameter mapping. If this isn't your case I'd appreciate a bug report. This is a place where we made a different design decision than you did -- a WAI application which expects to parse the POST body itself won't work. I'll think about adding a knob to make this behaviour optional. I'd appreciate such a knob. Out of curiosity, do you also parse multi-part data? No, not yet :(, and we'll never do so automatically; we limit POST bodies to 1MB or something like that (to prevent malicious requests from trashing the server) but multipart requests can contain file uploads, which we would probably want to be able to stream to disk somehow. If you're interested, you can look at the Network.Wai.Parse module in wai-extra. The parseRequestBody function takes an argument of type Sink that specifies how data should be stored. By default, I provide an lbsSink and tempFileSink. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] First Public Release of the Snap Framework
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
