[Haskell-cafe] Web application frameworks

Björn Bringert bringert at cs.chalmers.se
Tue Mar 7 12:09:40 EST 2006


Graham Klyne wrote:
> [Switching to haskell-cafe]
> Niklas Broberg wrote:

> ...

>>On 3/6/06, Graham Klyne <GK at ninebynine.org> wrote:
>>>- Options to run the whole thing behind Apache to leverage its security and web
>>>space management capabilities
>>
>>Lemmih has implemented a HSP/FastCGI binding for Apache. I also know
>>that work is being done on building a direct HSP/Apache binding. All
>>work in progress though.
> 
> Yes, I was aware of a fastCGI for Haskell.  Didn't Bjorn Bringert (also)
> implement one?  I tend to think of CGI programs as run-to-completion-then-exit,
> even when a fastCGI interface allows a persistent wrapper program to speed
> startup.  But I could easily be missing something here.

Yes, I have written a FastCGI binding (darcs repo here: 
http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/). If I'm not 
mistaken, that's what Lemmih is using for his HSP/FastCGI binding.

I have only used FastCGI the way you describe, as CGI without start-up 
penalty, though I can't see why you couldn't keep some state between 
requests to a FastCGI application. I believe that Ruby-on-Rails (which 
I've never used, so I'm not too sure) can use FastCGI.

One problem with Apache and FastCGI is that the Apache FastCGI module 
doesn't seem to support concurrent requests to a single FastCGI process 
(even though the FastCGI protocol allows this). This means that Apache 
will have to run several instances of the Haskell-over-FastCGI app to 
serve concurrent requests, or be forced to serialize the requests. 
Having several instances of course means that you can't really keep 
stuff like session data in memory in the FastCGI process. If the Apache 
module supported concurrent requests we could spawn a new Haskell thread 
to serve each request, which ought to scale well.

> ...

/Björn


More information about the Haskell-Cafe mailing list