[web-devel] Re: CGI

Curt Sampson ha scritto:

On 2009-02-21 12:23 +0100 (Sat), Johan Tibell wrote:

...

On Fri, Feb 20, 2009 at 3:17 PM, Manlio Perillo wrote:

...

I have some doubts about the name WAI. It means "Web application interface", but I think that the word "Gateway" should appear in it. I don't have a strong attachment to the name. I'm not sure what the word "gateway" means in this context, probably because I haven't studied CGI in depth.

It's fairly meaningless. CGI stands for "common gateway interface," and is basically:

A gateway is basically a program that sits between two other programs that speak different protocols. As an example, Mailman come with a gateway that allow the integration of Mailman with NNTP.

[...] I've spent more time than I care to over the last four or five years dealing with FastCGI on the application (i.e., opposite of web server) side, both as a client of existing libraries and a writer of new ones, and it's caused me much pain.

The one real

The only one, I would say. :)

advantage that FastCGI has is that it's supported across a lot of web servers, and some have some nice special features. For example, with lighttpd, you can avoid a lot of shoveling of data around by returning an "x-send-file: /some/path" header and no body;

This is not a FastCGI exclusive.

[...] But overall, I'd be much happier with a protocol that just handed me the raw HTTP request, and allowed me to send back a raw HTTP response.

It already exists, and it is called HTTP. FastCGI is an "complex for nothing" protocol that translate a nice text based protocol to a complex binary protocol. SCGI is what you should use, if you don't want to write an HTTP (1.0) server.

The issue is, of course, getting the protocol implemented in various web servers. I could, I suppose, design a new protocol and write a C implementation for lighttpd. But then, given that I'd hope to be talking to a Haskell application server anyway, GHC has great support for building efficient, multiprocessing, highly concurrent servers, and Haskell is about a hundred times nicer to program in than C, I think I'd just write a high-performance web server in Haskell. (Except that it's already been done, anyway.)

I, instead, think that Haskell is not yet mature for writing an high-performance web server.

[...]

Manlio Perillo