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 _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users