Re: [Chicken-users] Choosing a programming language for a web project

[Graham Fawcett]

In reply to an off-list message:
> Perhaps it is just me (I don't know much about these protocols), but I do
> not see the added value of yet another FastCGI/SCGI kind of interface.

WSGI is not another FastCGI/SCGI: it's a boundary between a
"front-end" protocol handler (such as an HTTP server, SCGI server, or
a CGI environment) and the "back-end" application framework. From the
framework's perspective, it provides an abstract model of what a
request looks like, and how to submit a response. With something like
WSGI, you could move your application from CGI to SCGI (for example)
without any significant rewriting of your code.

In my own mini-framework, my SCGI handler reads the request headers
into an a-list. (In SCGI, request headers are represented by CGI-style
environment variables.) The current input port is partially read by
the SCGI handler (to get the headers), but the rest of the request is
left for the "framework" to read. The framework is required to consume
the remainder of the request.

Response headers are represented by an (initially empty) a-list. The
current-output-port is mapped to a string-port: collecting the output
makes error-handling easier, and the buffering makes network
communication more efficient. When the framework has finished writing
the response, the SCGI handler consumes the response a-list, and the
string-port's value, and sends it back to the Web server in SCGI
format.

So, in my WSGI-like interface for Chicken, a request/response pair is
a 4-tuple, (incoming-request-headers, current-input-port,
current-output-port, outgoing-response-headers). The application
framework is represented by a single procedure that takes a 4-tuple as
an argument, and returns no value. Upon an inbound request, the
protocol side calls the procedure, and afterward it processes the
outbound headers and output string-port.

That, I think, is about as minimal as you can get, while still being
"robust" and being flexible enough to accommodate many protocols and
many app frameworks.

Thoughts?
Graham