Log in

No account? Create an account

mod_lisp is not like mod_otherlanguages

What's mod_otherlanguage like?

  • mod_perl: "...gives you a persistent Perl interpreter embedded in your web server."
  • mod_python: "...is an Apache module that embeds the Python interpreter within the server."
  • mod_tcl: "...includes a Tcl interpreter into an Apache web servers memory space, thus combining Tcl and Apache web server together."
  • ruby, PHP, Lua, Haskell, etc: all similar

mod_lisp isn't like that at all. It doesn't embed a Lisp system in Apache in any way. So what does it do?

mod_lisp is more like FastCGI. It's a small C module for Apache that handles a request by converting it to a simple text format, sending it over a socket to a Lisp system, and sending the Lisp system's response to the client. The socket is established on demand and can be kept alive for multiple requests.

If all you have is mod_lisp, you still need software to process the mod_lisp protocol and send a response. mod_lisp doesn't come bundled with any Lisp code to do that. There are several Lisp packages that make it easy, though. I use an old variation of Hunchentoot. Bill Clementson surveyed the Lisp web options a few years ago and mentions a few other options.

mod_lisp is not even really Lisp-specific; if you can multiplex network connections and parse simple text, you can write something in any language that works with mod_lisp. It's pretty likely that your language already has an Apache module or an interface to FastCGI, though, unless it's even more obscure than Lisp.





This is pretty much what mod_jk(used by Apache Tomcat) does

Re: mod_jk

To be honest, I've tried and failed to set up mod_jk several times, falling back to mod_proxy. And from what I've seen, I'm not alone with that.


Re: mod_jk

Mod_jk is very inflexible. I've set it up a couple times, but it sucks having to enumerate each directory that's going to have JSP content. When I have to tread that path again, I'm going with mod_rewrite/mod_proxy. It's the only way to let your developers just drop JSP files wherever they need to without administrator intervention.


I wonder why the original author didn't simply use FastCGI?

There is, I believe, a known issue with some FastCGI client implementations not liking talking to a multi-threaded FastCGI server; they prefer single thread, multiple OS process. Might be something to do with that...

Re: FastCGI

The fastcgi protocol looks much more complicated than mod_lisp. It's not hard for me to imagine that it would be easier to write mod_lisp from scratch than write an interface to FastCGI.

Nighmare scenario:



Re: Nighmare scenario:

Hmmm. I don't know. Maybe it's even possible today, interfacing mod_lisp to gnuclient/gnuserv.


From the protocol description, it's very similar to SCGI (http://www.mems-exchange.org/software/scgi/), for which there is an Apache module (mod_scgi), CGI adapters, and support in lighttpd.


Optimal Combination

So if I wanted to build a lisp based web app (which I do) using Lighttpd as the server (which I do) does anyone here have any suggestions about how best to wire the two together? Mod_lisp? FastCgi, SCGI. I'm confused.


Re: Optimal Combination

If I were starting today, I'd use mod_proxy, pound, or some other proxy and run Hunchentoot in HTTP mode instead of mod_lisp mode.


Re: Optimal Combination


thanks for tips.

most interesting that you would not use lighttpd.

Very helpful.


Re: Optimal Combination

I didn't list lighttpd because I don't know anything about it. If it can act as a proxy for some requests, it would be a fine candidate for working with Hunchentoot.

Re: Optimal Combination

It can. You can set it up to serve static content, and proxy dynamic requests to apache+mod_favoritelanguage or some other HTTP server pretty easily.


Re: Optimal Combination - examples

As xach said:
pound (as a proxy), lighttpd (static content) and hunchentoot (dynamic creatures)

check the following links for a general idea ...
(Note: replace ruby with common-lisp and mongrel with hunchentoot)





Which begs the question

Why reinvent FastCGI and limit yourself to Apache in the process?

And have to maintain 2 versions of your module across 1.x and 2.x.

This makes no sense to me.

Re: Which begs the question

History, context. As it is, it works fine.

Re: Which begs the question

...and if you were starting from scratch today, the available software and the decisions you make based on it would be different.