# cl-modlisp Documentation

## Overview

cl-modlisp provides the Lisp side of the interface to Marc Battyani's mod_lisp apache module (http://www.fractalconcept.com).

## Features

- support for AllegroCL, CMUCL, SBCL with sb-thread, and Lispworks.
- listener and worker socket/process management so that shutting down the listener closes all related open sockets and terminates all related proceses.
- support for running multiple command processors on multiple ports.
- transparent support for precomputing the HTML or XML response to take advantage of HTTP/1.1's Keep-Alive feature. This is switchable with a single keyword argument to the macro `with-ml-page`.
- Optional timeout of worker processes
- Two process models for flexibility
- Demonstration processor included

## Prerequisites

- Apache 1.3.x
- mod_lisp apache module (http://www.fractalconcept.com).
- kmrcl library (http://files.b9.com/kmrcl).
- asdf (http://www.sf.net/projects/cclan).

## Supported Platforms

- Allegro v6.2
- CMUCL 18e
- Lispworks v4.2
- SBCL 0.8.1 with sb-thread (multi-threading)

## Quickstart

- The easiest way to install is to use the Debian GNU/Linux operating system. Using the testing or unstable distributions, you can give the command:
  `apt-get install libapache-mod-lisp cl-modlisp cl-kmrcl`
  If you are not using Debian, you will need to download and install mod_lisp, cl-modlisp, and cl-kmrcl manually.
- Add something like the below to httpd.conf and then restart apache
  `LispServer 127.0.0.1 20123 "localhost"`
  `AddHandler lisp-handler .lsp`
- Start your Lisp implementation and load cl-modlisp with
  `(asdf:operate 'asdf:load-op 'modlisp)`
- Start the server with
  `(ml:modlisp-start :port 20123)`
- Try some demostration pages
  `links http://localhost/fixed.lsp`
  `links http://localhost/debug.lsp`
- Shutdown the all cl-modlisp servers with
  `(ml:modlisp-stop-all)`

## Process Models

There are two process models

- Each connection spawns a new thread
  This is the default model. Each new connection to listener socket spawns a new connection. This allows for an arbitrary number of concurrent connections. This has advantages if the workers require a long execution time.
- Fixed pool of workers
  This model is selected by passing the number of worker processes to `init/listener` with the keyword `number-fixed-workers`. This model has a lower overhead since new processes are not created and destroyed with each connection. It has advantages when the workers have a short execution time.

## Usage

The demo.lisp file for examples of using 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 lengthye 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/