Subject: Re: Review of CL web server APIs: (1) Araneida
Newsgroups: gmane.lisp.web
Date: 2003-08-19 16:28:46 GMT (5 years, 45 weeks, 4 days, 19 hours and 21 minutes ago)
> Daniel Barlow wrote: > Ok, that's Araneida in a nutshell. Next up? Someone want to tackle > paserve or cl-modlisp? As author cl-modlisp, I'll be glad to do so. Nice summary on Araneida. * cl-modlisp ** Overview cl-modlisp is a multi-threaded handler for HTTP requests forwarded by Marc Battyani's (http://www.fractalconcept.com) mod_lisp Apache module. ** Design Goals cl-modlisp is designed as a thin layer to dispatch a mod_lisp request with multi-platform compatibility. Currently, cl-modlisp supports SBCL [multithreaded], CMUCL, AllegroCL, and Lispworks. ** Dispatch model Extremely simple: All requests are forwarded to a single processor that is passed as a parameter to cl-modlisp's start-up function. ** Configuration All configuration is set by passing keyword arguments to modlisp-start: port number - a number processor - function designator which will receive all requests processor-args - list of extra arguments to be passed to processor timeout - NIL means never timeout otherwise number of seconds catch-errors - non-NIL means to catch errors number-fixed-workers - NIL means to spawn a new worker process for each request remote-host-checker - optional function designator to check the remote host IP address. Used for filtering requests. ** Processor function This function receives an argument of the "command" alist and any other arguments passed to modlisp-start as the :processor-args. The "command" alist is an associative list of keys and values received from modlisp. No preprocessing is done except that keys are converted from strings to keywords forced to the default implementation case. ** Default Processor The default processor is a simple demo command processor not intended for end-user. ** URI Processing None. The raw URL is the value of the :url key in the command alist. ** Responses Responses are written to modlisp:*modlisp-socket*. The raw HTTP/1.1 header needs to be generated by the application. ** Utility functions A few utility functions are provided: with-ml-page: Outputs the body of the macro along with the HTTP/1.1 headers. Supports both precomputing responses with keep-alive connections and also outputing response to socket as it is generated. The latter is useful for lengthy reponses in time or length. Also support setting the content-type (default "text/html") and arbitrary list of headers query-to-alist: Converts posted query to an alist. Doesn't handle multipart forms. redirect-to-location ** Known issues This application has been most tested on AllegroCL. By design, is not practical an application platform. It is should have an API package wrapped around this library which supports useful features like processing URIs, dispatches, cookies, and querys [URI and single/multipart POSTs] Rather than adding these features to cl-modlisp, I've been working on a library which uses a session-id and dispatch model based on Franz's webactions library. It also integrates my portable version of Franz's URI module and adds query processing similar on AllegroServer's request-query functions. This library can used with both cl-modlisp and AllegroServe as connectors. However, as this library has grown, it looks more and more like AllegroServe, I've begun to question the value of using this library compared to just using Portable AllegroServe with just my webactions-like session-id and dispatch processors. In my mind, the greatest advantage of using this library is that it is a much smaller task maintaining cross-implementation compatibility with the cl-modlisp connector version maintaining such compatibility with paserve. The disadvantage of this library is that I dislike cloning AllegroServe's query and cookie processing. I do so, though, because I think their API is quite reasonable. This library is currently driving http://umlisp.b9.com/ Kevin