[email protected]
[Top] [All Lists]

[Haskell-cafe] Re: PROPOSAL: Web application interface

Subject: [Haskell-cafe] Re: PROPOSAL: Web application interface
From: Bardur Arantsson
Date: Sun, 24 Jan 2010 12:23:46 +0100
Michael Snoyman wrote:

Next, I have made the ResponseBodyClass typeclass specifically with the goal
of allowing optimizations for lazy bytestrings and sending files. The former
seems far-fetched; the latter provides the ability to use a sendfile system
call instead of copying the file data into memory. However, in the presence
of gzip encoding, how useful is this optimization?

I'm hoping that the "Web" bit in your project title doesn't literally mean that WAI is meant to be restricted to solely serving content to browsers. With that caveat in mind:
For non-WWW HTTP servers it can be extremely useful to have sendfile. An
example is my Haskell UPnP Media Server (hums) application. It's sending
huge files (AVIs, MP4s, etc.) over the network and since these files are
already compressed as much as they're ever going to be, gzip would be
useless. The CPU load of my hums server went from 2-5% to 0% when
streaming files just from switching from a Haskell I/O based solution to
proper sendfile.
Lack of proper support for sendfile() was indeed one of the reasons that
I chose to roll my own HTTP server for hums. I should note that this was
quite a while ago and I haven't really gone back to reevaluate that
choice -- there's too many HTTP stacks to choose from right now and I
don't have the time to properly evaluate them all.
For this type of server, response *streaming* is also extremely
important for those cases where you cannot use sendfile, so I'd hate to
see a standard WAI interface preclude that. (No, lazy I/O is NOT an
option -- the HTTP clients in a typical UPnP media client behave so
badly that you'll run out of file descriptors in no time. Trust me, I've

Haskell-Cafe mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>