[Haskell-cafe] Web application interface

[Michael Snoyman]

Hey Jeremy,

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.

Thanks,
Michael

On Thu, Jan 14, 2010 at 5:42 PM, Jeremy Shaw <jeremy at n-heptane.com> wrote:

> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100121/0865ad65/attachment.html