[web-devel] Re: CGI

[Manlio Perillo]

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
>> <manlio_perillo at libero.it> 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