Re: [Haskell-cafe] Web application frameworks

Björn Bringert wrote:

Graham Klyne wrote:

...

[Switching to haskell-cafe] Niklas Broberg wrote:

...

...

...

...

On 3/6/06, Graham Klyne 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.

Aha! I think that homes in on what I was after when mentioning long-running processes. I think there are some separate but related issues to consider: (a) can a single CGI invocation handle (respond to) a series of HTTP requests, or is it strictly one http request for each CGI invocation? Without this, you may have to throw away session state after each request. (b) is there a way to maintain state between CGI invocations? (c) can multiple concurrent CGI/HTTP requests be handled? Of these, I think (c) may be the least important, other than for performance reasons (and maybe not even then), provided that there are ways to handle upstream I/O asynchronously, and to encapsulate all the relevant session state in a way that can be passed between invocations. I guess it comes down to a choice between an event-driven or multi-threaded processing model (and the former seems to me to be a nicer fit with Haskell). I think the minimum requirement is ((a) OR (b)) AND ((c) OR (asynchronous I/O completion)) #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact