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

[Nicolas Pouillard]

On Sun, 24 Jan 2010 12:23:46 +0100, Bardur Arantsson <spam at scientician.net> wrote:
> Michael Snoyman wrote:
> 
> [--snip--]
> > 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?
> [--snip--]
> 
> 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.

Good reason indeed.

> 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 
> tried.)

Is the experiment easily re-doable? I would like to try using safe-lazy-io
instead.

-- 
Nicolas Pouillard
http://nicolaspouillard.fr