[Haskell-cafe] Web application frameworks

[Graham Klyne]

Björn Bringert wrote:
> 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.

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