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@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
