mod_lisp is not like mod_otherlanguages
« previous entry | next entry »
Nov. 15th, 2007 | 02:39 pm
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.
mod_jk
from: anonymous
date: Nov. 15th, 2007 08:59 pm (UTC)
Link
Reply | Thread
Re: mod_jk
from:
abas.videntity.org
date: Nov. 16th, 2007 10:30 am (UTC)
Link
Reply | Parent | Thread
Re: mod_jk
from: anonymous
date: Nov. 16th, 2007 08:32 pm (UTC)
Link
Reply | Parent | Thread
FastCGI
from:
rsynnott [typekey.com]
date: Nov. 15th, 2007 10:06 pm (UTC)
Link
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...
Reply | Thread
Re: FastCGI
from:
xach
date: Nov. 16th, 2007 12:11 am (UTC)
Link
Reply | Parent | Thread
Nighmare scenario:
from:
smitty1e
date: Nov. 16th, 2007 02:26 am (UTC)
Link
Reply | Thread
Re: Nighmare scenario:
from: anonymous
date: Nov. 16th, 2007 07:39 am (UTC)
Link
Reply | Parent | Thread
SCGI
from:
isobaric.ca
date: Nov. 16th, 2007 10:07 am (UTC)
Link
Reply | Thread
Optimal Combination
from: anonymous
date: Nov. 16th, 2007 11:01 am (UTC)
Link
Giaccomo
Reply | Thread
Re: Optimal Combination
from:
xach
date: Nov. 16th, 2007 11:41 am (UTC)
Link
Reply | Parent | Thread
Re: Optimal Combination
from: anonymous
date: Nov. 16th, 2007 11:59 am (UTC)
Link
thanks for tips.
most interesting that you would not use lighttpd.
Very helpful.
Giaccomo
Reply | Parent | Thread
Re: Optimal Combination
from:
xach
date: Nov. 16th, 2007 12:27 pm (UTC)
Link
Reply | Parent | Thread
Re: Optimal Combination
from:
sapphirecat
date: Nov. 16th, 2007 05:07 pm (UTC)
Link
Reply | Parent | Thread
Re: Optimal Combination - examples
from: anonymous
date: Nov. 16th, 2007 07:48 pm (UTC)
Link
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)
http://www.theblatherskite.com/articles/2
http://www.aidanf.net/node/36
http://blog.tupleshop.com/2006/7/8/deplo
regards,
cmo-0
Reply | Parent | Thread
Which begs the question
from: anonymous
date: Nov. 16th, 2007 08:37 pm (UTC)
Link
And have to maintain 2 versions of your module across 1.x and 2.x.
This makes no sense to me.
Reply | Thread
Re: Which begs the question
from:
xach
date: Nov. 16th, 2007 08:39 pm (UTC)
Link
Reply | Parent | Thread
Re: Which begs the question
from:
xach
date: Nov. 16th, 2007 08:41 pm (UTC)
Link
Reply | Parent | Thread