[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