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

[Michele Simionato]

On 10/2/07, Graham Fawcett <address@hidden> wrote:
> 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.

I will just add a relevant link:
http://wsgi.org/wsgi

See also the WSGI 2.0 specification, where the minimal application is something
like

def app(environ):
    return '200 OK', [('Content-type', 'text/plain')], ['Hello world']

> 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?

I am not convinced by the current-output-port. In WSGI you return an
iterator over strings (say a list) so that middleware can further process it.
Post-processing the current-output-port looks more cumbersome.
Just my 0.02c,

                  Michele Simionato