<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello,<div><br></div><div>In happstack, there is a Writer monad which holds a list of filters which will be applied to the Response before sending it out. One of these filters is the gzip filter. </div><div><br></div><div>The compression filters are defined here:</div><div><br></div><div><a href="http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-server/src/Happstack/Server/Parts.hs">http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-server/src/Happstack/Server/Parts.hs</a></div><div><br></div><div>The filters are apply when runWebT is called:</div><div><br></div><div><a href="http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-server/src/Happstack/Server/SimpleHTTP.hs">http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-server/src/Happstack/Server/SimpleHTTP.hs</a></div><div><br></div><div>runWebT is called automatically by the top-level function, simpleHTTP, that people actually call in their programs.</div><div><br></div><div><br></div><div>We do not do anything fancy to cache gzip results to the disk. We don't even assume you *have* a disk. I believe that functionality could be added as a 3rd party library with out modifying core happstack. That is how we would prefer to see it done so that the core is simple, and so that people can implement their own caching system if their needs are different.</div><div><br></div><div>- jeremy</div><div><br><div><div>On Jan 21, 2010, at 10:37 PM, Michael Snoyman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hey Jeremy,<br><br>I was just wondering: how does Happstack deal with gzip encoding when it uses sendfile? I can think of a few ways (cache gziped versions to the disk), but was wondering if you'd already come up with a good solution. I'm trying to keep all these things in mind when designing WAI.<br> <br>Thanks,<br>Michael<br><br><div class="gmail_quote">On Thu, Jan 14, 2010 at 5:42 PM, Jeremy Shaw <span dir="ltr"><<a href="mailto:jeremy@n-heptane.com">jeremy@n-heptane.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hello,<br> <br> Happstack is currently bundled with it's own lazy I/O based HTTP backend. Ideally, we would like to split that out, and allow happstack to be used with that backend, hyena, or other options.<br> <br> A primary using for using hyena would be for the benefits of predictability and constant space usage that iterators bring. People do actually running into the issues that come with lazy I/O, such as running out of file descriptors, etc. So, I feel like I would want to stick with using iterators the whole way when using hyena, and not convert back to a lazy ByteString?<br> <br> Happstack now includes support for sendfile(). This is done by adding another constructor to the Response type:<br> <br> (line 94):<br> <a href="http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-server/src/Happstack/Server/HTTP/Types.hs" target="_blank">http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-server/src/Happstack/Server/HTTP/Types.hs</a><br> <br> Then here on line 197, we match on that case and use sendfile to send the data:<br> <br> <a href="http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-server/src/Happstack/Server/HTTP/Handler.hs" target="_blank">http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-server/src/Happstack/Server/HTTP/Handler.hs</a><br> <br> This makes it difficult for use to be compatible with WAI. We can write a wrapper that converts the sendfile case to use lazy bytestrings instead, but then we lose the advantages of using sendfile.<br> <br> I wonder if the 'Response' portion of WAI should support all three currently used methods:<br> - lazy I/O<br> - Enumerator<br> - sendFile<br> <br> I haven't really thought about how that would work..<br> <br> hyena currently includes a Network.WAI which uses ByteString:<br> <br> <a href="http://hackage.haskell.org/packages/archive/hyena/0.1/doc/html/Network-Wai.html" target="_blank">http://hackage.haskell.org/packages/archive/hyena/0.1/doc/html/Network-Wai.html</a><br> <br> gotta run, sorry about any typos!<br><font color="#888888"> - jeremy</font><div><div></div><div class="h5"><br> <br> <br> On Jan 13, 2010, at 8:46 AM, Michael Snoyman wrote:<br> <br> </div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5"> Hi,<br> <br> I recently read (again) the wiki page on a web application interface[1] for Haskell. It seems like this basically works out to Hack[2], but using an enumerator instead of lazy bytestring in the response type. Is anyone working on implementing this? If not, I would like to create the package, though I wouldn't mind some community input on some design decisions:<br> <br> * Hack has been fairly well-tested in the past year and I think it provides the features that people want. Therefore, I would want to model the Environment variable for WAI from Hack. I *could* just import Hack in WAI and use the exact same Environment data type. Thoughts?<br> <br> * If using a different data type for Environment, should I replace the String parts with ByteStrings? On the one hand, ByteStrings are the "correct" data type since the HTTP protocol does not specify a character encoding; on the other hand, Strings are easier to deal with.<br> <br> * It's simple to write a function to convert between a lazy bytestring and an enumerator, meaning it would be very easy to write conversion functions between Hack and WAI applications. This would make it simpler for people to use either backend.<br> <br> If someone else is already working on WAI, please let me know, I don't want to have duplicate implementations. The idea here is to consolidate, not split the community. I have a few Hack handlers (simpleserver, cgi, fastcgi) that I would happily convert to WAI handlers as well.<br> <br> Michael<br> <br> [1] <a href="http://www.haskell.org/haskellwiki/WebApplicationInterface" target="_blank">http://www.haskell.org/haskellwiki/WebApplicationInterface</a><br> [2] <a href="http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hack" target="_blank">http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hack</a><br></div></div><div class="im"> _______________________________________________<br> Haskell-Cafe mailing list<br> <a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br> </div></blockquote> <br> </blockquote></div><br></div></blockquote></div><br></div></body></html>