[Haskell-cafe] Web application interface

[Jeremy Shaw]

Hello,

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.

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?

Happstack now includes support for sendfile(). This is done by adding  
another constructor to the Response type:

(line 94):
http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-server/src/Happstack/Server/HTTP/Types.hs

Then here on line 197, we match on that case and use sendfile to send  
the data:

http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-server/src/Happstack/Server/HTTP/Handler.hs

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.

I wonder if the 'Response' portion of WAI should support all three  
currently used methods:
   - lazy I/O
   - Enumerator
   - sendFile

I haven't really thought about how that would work..

hyena currently includes a Network.WAI which uses ByteString:

http://hackage.haskell.org/packages/archive/hyena/0.1/doc/html/Network-Wai.html

gotta run, sorry about any typos!
- jeremy


On Jan 13, 2010, at 8:46 AM, Michael Snoyman wrote:

> Hi,
>
> 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:
>
> * 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?
>
> * 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.
>
> * 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.
>
> 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.
>
> Michael
>
> [1] http://www.haskell.org/haskellwiki/WebApplicationInterface
> [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hack
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe