A short announcement: Some of you have might have already noticed the
use of URLs for the Common Lisp Directory that indicate that Python
code is used. It's indeed the case that we have switched from a
server application based on Common Lisp to one based on Python. The
reason is that we had some problems with regard to multithreading and
the HTML code generation utilities that we use. In order not to risk
any stability issues, we have quickly rewritten the whole application
logic in Python, and it seems that everything works well now. We will
give a fully detailed report of the problems of using Common Lisp in
web application development in a few days when the transition is
finished and fully tested.
Some of you might now think that this is a bad case of not eating our
own dog food, but it's simply better to be pragmatic here and use a
solution that actually works instead of spending time on fixing
complex interactions between incompatible libraries. Needless to say
that we stand fully committed behind Common Lisp and especially the
Common Lisp Directory, due to its popularity with users and its
recognition in major search engines (Google, etc.) in a very short
amount of time. For the time being, we will stick to Python for the
Common Lisp Directory, but will reevaluate the situation in the
coming months.
The Common Lisp Directory is here: http://www.cl-user.net/web.py/root-dir
------
The Common Lisp Directory administrators.
"Marc Battyani" <·············@fractalconcept.com> writes:
> A short announcement: Some of you have might have already noticed the
> use of URLs for the Common Lisp Directory that indicate that Python
> code is used. It's indeed the case that we have switched from a
> server application based on Common Lisp to one based on Python.
In related news, Franz announced today that they are moving their focus
from Lisp to Java, due to customer demand.
--
vedm
From: Duane Rettig
Subject: Re: The Common Lisp Directory rewritten in Python
Date:
Message-ID: <o0fykxqabj.fsf@franz.com>
vedm <··@ns.com> writes:
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
>> A short announcement: Some of you have might have already noticed the
>> use of URLs for the Common Lisp Directory that indicate that Python
>> code is used. It's indeed the case that we have switched from a
>> server application based on Common Lisp to one based on Python.
>
> In related news, Franz announced today that they are moving their focus
> from Lisp to Java, due to customer demand.
LOL. I had a good laugh over this one. Interestingly, though, if you
search on our site for the word "java", you'll get 10 pages of hits...
I suppose if you had mentioned a shift in focus from concentrating on
Lisp only to concentrating on _communication_ with external langauages
as well, I would have taken this much more seriously, but would have
also pointed out that that was old news; we've concentrated heavily on
communication with several extrnal languages for many, many years.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
vedm <··@ns.com> writes:
> In related news, Franz announced today that they are moving their
> focus from Lisp to Java, due to customer demand.
And GNU revealed their plans to rewrite Emacs in Perl
http://article.gmane.org/gmane.emacs.devel/52306
--
Johan Bockgård
On Sun, 02 Apr 2006 01:50:31 +0200, Johan Bockg�rd
<············@dd.chalmers.se> wrote:
> And GNU revealed their plans to rewrite Emacs in Perl
>
> http://article.gmane.org/gmane.emacs.devel/52306
Finally my project has gotten the green light.
http://groups.google.com.au/group/fido7.ru.linux/msg/4c279bec49b5925e
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
From: Ken Tilton
Subject: Re: The Common Lisp Directory rewritten in Python
Date:
Message-ID: <_0wXf.786$n13.76@fe12.lga>
Marc Battyani wrote:
> A short announcement: Some of you have might have already noticed the
> use of URLs for the Common Lisp Directory that indicate that Python
> code is used. It's indeed the case that we have switched from a
> server application based on Common Lisp to one based on Python. The
> reason is that we had some problems with regard to multithreading and
> the HTML code generation utilities that we use.
I was kinda hoping to do some Web app work using a CL system. Could you
share a little more about the stack you abandoned, any alternative CL
frameworks you rejected for what reason? [Oops. See below] I do not mean
a treatise, just "we were using X (too Z), considered Y (same Z), went
with (which one based on Python?)".
Also, not Ruby on Rails? The Reddit folks seemed to be close to a strong
Python person (possibly even a Web app developer?) and Python was a
second langugae for them so I can see them taking the quick way out.
Did you look at?: http://homepage.mac.com/svc/RebelWithACause/index.html
Any plans to work your way back to CL with a project to cure the ills?
> In order not to risk
> any stability issues, we have quickly rewritten the whole application
> logic in Python, and it seems that everything works well now. We will
> give a fully detailed report of the problems of using Common Lisp in
> web application development in a few days when the transition is
> finished and fully tested.
Oh. Never mind. :)
One scary thought is that I cannot imagine the site having that much
traffic, so the existing tools (or at least the ones tried) must have
serious problems.
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton <·········@gmail.com> wrote:
> I was kinda hoping to do some Web app work using a CL system. Could you
> share a little more about the stack you abandoned, [...]
I think you just got a fish sticked to your back :-)
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Ken Tilton wrote:
> One scary thought is that I cannot imagine the site having that much
> traffic, so the existing tools (or at least the ones tried) must have
> serious problems.
One of the authors of BKNR mailed me, that they have used BKNR for 2 years
for a website with about 20,000 hits per hour with aserve on FreeBSD behind
a squid proxy, so looks like it is possible to use Lisp for
webapplications, if you carfully choose the right frameworks and program
combinations. I've tried aserve, too, but probably it is not a good idea to
expose it without Apache or some other proxy or redirector to the internet,
because in my case aserve stopped delivering webpages after some hours.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
In article <································@40tude.net>,
Frank Buss <··@frank-buss.de> wrote:
> Ken Tilton wrote:
>
> > One scary thought is that I cannot imagine the site having that much
> > traffic, so the existing tools (or at least the ones tried) must have
> > serious problems.
>
> One of the authors of BKNR mailed me, that they have used BKNR for 2 years
> for a website with about 20,000 hits per hour with aserve on FreeBSD behind
> a squid proxy, so looks like it is possible to use Lisp for
> webapplications, if you carfully choose the right frameworks and program
> combinations. I've tried aserve, too, but probably it is not a good idea to
> expose it without Apache or some other proxy or redirector to the internet,
> because in my case aserve stopped delivering webpages after some hours.
President Clinton had the White House publications server written
in Lisp running for some time on the Internet, serving american
citizens with informations about his affairs. President Bush pulled
the plug of that server after he got elected very fast. Go figure!
--
http://lispm.dyndns.org/
Stefan Ram wrote:
> Rainer Joswig <······@lisp.de> writes:
> >President Clinton had the White House publications server written
> >in Lisp running for some time on the Internet, serving american
> >citizens with informations about his affairs. President Bush pulled
> >the plug of that server after he got elected very fast. Go figure!
>
> Is it known, whether anyone of them both is personally aware
> of this, or has at least some knowledge what »Lisp« means?
Can't say much about Bush, but atleast in Clinton's administration
a small group knew, especially since they were hosting two Virtual
Lisp Machines (on DEC Alpha) from 1994 to 2000 for that purpose. ;-)
There
were also one or two other projects done (one for the vice president
Al Gore) with this technology.
Ken Tilton <·········@gmail.com> writes:
> I was kinda hoping to do some Web app work using a CL system. Could
> you share a little more about the stack you abandoned, any alternative
> CL frameworks you rejected for what reason? [Oops. See below] I do not
Marc can provide you with the technical details, but this is the tool
that he finally ended up using:
http://www.cl-user.net/web.py/libs/web-py-apr1
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
On 2006-04-01 08:32:53 -0500, "Marc Battyani"
<·············@fractalconcept.com> said:
> The Common Lisp Directory is here: http://www.cl-user.net/web.py/root-dir
Interestingly, this URL:
<http://www.cl-user.net/web.py/>
gives configuration settings that mention a modlisp-version (2.41)
And it is April 1st...
From: Ken Tilton
Subject: Re: The Common Lisp Directory rewritten in Python
Date:
Message-ID: <yIzXf.139$fE4.52@fe09.lga>
Raffael Cavallaro wrote:
> On 2006-04-01 08:32:53 -0500, "Marc Battyani"
> <·············@fractalconcept.com> said:
>
>> The Common Lisp Directory is here: http://www.cl-user.net/web.py/root-dir
>
>
> Interestingly, this URL:
> <http://www.cl-user.net/web.py/>
>
> gives configuration settings that mention a modlisp-version (2.41)
>
> And it is April 1st...
>
Doh!
ROFL
ken (still intrigued by KPAX, tho)
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
On 2006-04-01 13:48:36 -0500, Stefan Scholl <······@no-spoon.de> said:
> Kevin Spacey really rocks in this
> movie.
Yes, he's particularly animated in the catatonic scenes.
Seriously, Sven Van Caekenberghe's KPAX does look really nice, and his
cl-prevalence is pretty cool too.
Marc Battyani wrote:
> It's indeed the case that we have switched from a
> server application based on Common Lisp to one based on Python. The
> reason is that we had some problems with regard to multithreading and
> the HTML code generation utilities that we use.
So don't forget to add some notes to the Lisp frameworks you've used to the
directory descriptions that they are currently crap and everybody should
use Python instead ;-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Wade Humeniuk
Subject: Re: The Common Lisp Directory rewritten in Python
Date:
Message-ID: <qoxXf.11751$Ph4.1314@edtnps90>
So you were using a HTML generation library that was not
MT safe. Since the problem was not fixed by the placement
of a few good mutexes I have to assume that the library is
non-reentrant. That must be embarrassing.
Wade
From: Ken Tilton
Subject: Re: The Common Lisp Directory rewritten in Python
Date:
Message-ID: <ofzXf.18$rY6.13@fe10.lga>
Wade Humeniuk wrote:
> So you were using a HTML generation library that was not
> MT safe. Since the problem was not fixed by the placement
> of a few good mutexes I have to assume that the library is
> non-reentrant. That must be embarrassing.
Man, the Reddit guys sure are off the hook. :)
Speaking of which, has this catastrophe been picked up there or on any
of the other yak-yak sites?
I predict that we can add to the Lisp rap sheet (slow, interpreted,
weird syntax) a new unshakeable reputation: can't even do a Web app!
Hey, Peter. How is the Lisp on Rails thing coming? :)
me, I finally read/saw this today:
http://homepage.mac.com/svc/LispMovies/index.html#2
Cool. I happen to have an XServe collocated some place idling away
waiting for me to write some code.
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
"Marc Battyani" <·············@fractalconcept.com> writes:
> code is used. It's indeed the case that we have switched from a
> server application based on Common Lisp to one based on Python. The
[...]
> Some of you might now think that this is a bad case of not eating our
> own dog food, but it's simply better to be pragmatic here and use a
> solution that actually works instead of spending time on fixing
> complex interactions between incompatible libraries. Needless to say
This is indeed an unfortunate but necessary decision.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
From: Friedrich Dominicus
Subject: Re: The Common Lisp Directory rewritten in Python
Date:
Message-ID: <87d5g0scwu.fsf@flarge.here>
congrats, a good one ;-)
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Friedrich Dominicus wrote:
> congrats, a good one ;-)
Especially on april fool's day. For a short moment I had thought the
Lispers went mad. Python for Lisp hopefully only in one particular day
of the year.
Schneewittchen
F�rster vom Silberwald <··········@hotmail.com> wrote:
>
> Friedrich Dominicus wrote:
>> congrats, a good one ;-)
>
> Especially on april fool's day. For a short moment I had thought the
> Lispers went mad. Python for Lisp hopefully only in one particular day
> of the year.
For me it's every day.
$ lisp
; Loading #P"/home/stesch/.cmucl-init.lisp".
CMU Common Lisp 19c (19C), running on parsec
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Fri, 2006-03-31 21:45:56+02:00 on parsec
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47
"F�rster vom Silberwald" <··········@hotmail.com> writes:
> Especially on april fool's day. For a short moment I had thought the
> Lispers went mad. Python for Lisp hopefully only in one particular day
> of the year.
Not necessarily:
PythOnLisp
http://common-lisp.net/project/python-on-lisp/
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: The Common Lisp Directory rewritten in Python
Date:
Message-ID: <87wte65vyw.fsf@qrnik.zagroda>
Paolo Amoroso <·······@mclink.it> writes:
>> Especially on april fool's day. For a short moment I had thought the
>> Lispers went mad. Python for Lisp hopefully only in one particular day
>> of the year.
>
> Not necessarily:
>
> PythOnLisp
> http://common-lisp.net/project/python-on-lisp/
This is a very primitive binding with limited capabilities of mixing
Lisp with Python. It doesn't support wrapping Python objects in Lisp
nor vice versa. Bridges between languages can be much more seamless
and more practical than that.
Here data is passed from Python to Lisp by redirecting Python's stdout
to a global file-like object which appends data to a Lisp string
(only text can be passed), or by giving Python a module with functions
implemented in Lisp (integers and strings can be passed). Data is
passed from Lisp to Python by embedding it in Python code string,
or by the mentioned callbacks (integers and strings only).
Some other features it doesn't support, which are supported by my
binding between Python and my language:
- Automatic conversion, wrapping, or unwrapping of objects, according
to their their runtime types, in both directions.
- Integration of garbage collectors (cycles which span languages are
not collected though).
- Exposing functions, sequences, dictionaries, and numbers from either
language as objects providing the corresponding native interfaces of
the other language.
- Accessing fields of objects of the other language.
- Automatic propagation of exceptions.
- Integration of thread systems: threads created by either language
may call the other language, synchronize with other threads etc.
I plan to make a bridge between my language and Lisp some day.
Then Lisp will be able to access Python more conveniently: via
a combination of both bridges :-)
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Marc Battyani
Subject: Back to Lisp (was: The Common Lisp Directory rewritten in Python)
Date:
Message-ID: <iN2dnWP6kdOwma3ZRVny2A@giganews.com>
"Marc Battyani" <·············@fractalconcept.com> wrote
>A short announcement: Some of you have might have already noticed the
> use of URLs for the Common Lisp Directory that indicate that Python
> code is used. It's indeed the case that we have switched from a
> server application based on Common Lisp to one based on Python. The
> reason is that we had some problems with regard to multithreading and
> the HTML code generation utilities that we use. In order not to risk
> any stability issues, we have quickly rewritten the whole application
> logic in Python, and it seems that everything works well now. We will
> give a fully detailed report of the problems of using Common Lisp in
> web application development in a few days when the transition is
> finished and fully tested.
>
> Some of you might now think that this is a bad case of not eating our
> own dog food, but it's simply better to be pragmatic here and use a
> solution that actually works instead of spending time on fixing
> complex interactions between incompatible libraries. Needless to say
> that we stand fully committed behind Common Lisp and especially the
> Common Lisp Directory, due to its popularity with users and its
> recognition in major search engines (Google, etc.) in a very short
> amount of time. For the time being, we will stick to Python for the
> Common Lisp Directory, but will reevaluate the situation in the
> coming months.
OK finally, we decided on April 2 to go back to the Lisp version ;-)
So now the Common Lisp Directory is back to:
http://www.cl-user.net/asp/root-dir
(BTW this makes me thinks that I should drop the asp as well... :)
In fact as probably anyone has found now, the Common Lisp Directory has
never been rewritten in Python. It was just an April 1 joke for insiders
(remember the R affair...)
A more detailed report on the Common Lisp Directory experience will follow.
Marc
From: Marc Battyani
Subject: Some feedback about the The Common Lisp Directory project. (And no, it's not in Python... ;-)
Date:
Message-ID: <5d6dnXfFKLidg63ZnZ2dnUVZ8tydnZ2d@giganews.com>
"Marc Battyani" <·············@fractalconcept.com> wrote
>A short announcement: Some of you have might have already noticed the
> use of URLs for the Common Lisp Directory that indicate that Python
> code is used.
As most of you have probably found out now, the switch of the Common Lisp
Directory to Python was only effective on April First. ;-)
Here are some feedback and real life data from the Common Lisp Directory
project.
Hardware: 1Gb Dual Intel Xeon 2.80GHz Debian box.
Software: Apache+mod_lisp+Lispworks
Some data taken on April 2 (in decreasing order :):
42 041 200 Hits since the Dec 15 2005 (start of the linkit project)!
41 997 354 Hits served by the same Lisp process, the other ones are the
logo/jpg etc. (with a max at 930K hits/day and several days with more than
800K hits)
34591 user sessions (robots excluded)
612 registered users
589 items:
287 Libraries/Tools/Software
155 People
101 Documents/Web sites
22 Implementations
15 Groups/Organizations
9 Events
First some explanation about why so many hits:
As some of you already know, my framework is intended for complex real time
collaborative applications and for that there is a 2 seconds Ajax like keep
alive/bidirectional connection. In the case of a public application like the
cl-directory this continuous connection is not useful but induces a lots of
hits. For now, I've reduced the connection frequency to 5 seconds and I will
suppress it completely for all the non interactive pages in the future.
Anyway this highlights the rock solid stability and reliability of a Lisp
webapp. The Lisp image is the same one from December. It has never crashed,
though the application have evolved from linkit (an improved reddit like
app) to the cl-directory with several versions that have completely changed
the applicative and object model.
> server application based on Common Lisp to one based on Python. The
> reason is that we had some problems with regard to multithreading and
> the HTML code generation utilities that we use.
On the contrary, the hability to blend the HTML generation in the Lisp code
through HTML macros is far better than every alternative that I know of.
[...]
> Needless to say
> that we stand fully committed behind Common Lisp and especially the
> Common Lisp Directory, due to its popularity with users and its
> recognition in major search engines (Google, etc.) in a very short
> amount of time.
At least that part of the message is true. After only 2.5 month with some
real content, the Common Lisp Directory already consistently appears in the
very first links for a lot of common lisp related searches on Google.
Sometimes it's even the first one!
So don't worry, the CLD will stay in Common Lisp and will continue to
improve. The next version (when I find some time to play with this) will
enable anybody to edit the CLD content but still in a moderated way to avoid
being spammed
In the mean time you can already add notes and comments to the directory
pages and of course submit new pages.
BTW some people have complained that they could not edit their own
libraries/persons/etc. entries. In that case just send us an email with your
cl-directory user login name and we will give you the modification rights
you want.
As a conclusion, I would say that Common Lisp has once again proven to be a
very good way to very quickly build rock solid and reliable web
applications.
Marc
From: Frank Buss
Subject: Re: Some feedback about the The Common Lisp Directory project. (And no, it's not in Python... ;-)
Date:
Message-ID: <175kc3zcuqso3$.145glpih1e44i.dlg@40tude.net>
Marc Battyani wrote:
> Hardware: 1Gb Dual Intel Xeon 2.80GHz Debian box.
> Software: Apache+mod_lisp+Lispworks
Why do you use an Apache module for forwarding requests with another socket
connection from the Apache module to the Lisp server instead of accepting
the internet requests in Lisp, only?
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Marc Battyani
Subject: Re: Some feedback about the The Common Lisp Directory project. (And no, it's not in Python... ;-)
Date:
Message-ID: <7fadnQi6qOQ71q3ZRVnyiw@giganews.com>
"Frank Buss" <··@frank-buss.de> wrote
> Marc Battyani wrote:
>
>> Hardware: 1Gb Dual Intel Xeon 2.80GHz Debian box.
>> Software: Apache+mod_lisp+Lispworks
>
> Why do you use an Apache module for forwarding requests with another
> socket
> connection from the Apache module to the Lisp server instead of accepting
> the internet requests in Lisp, only?
Well maybe because I wrote it... ;-)
In fact there are lots of reasons for mod_lisp, some of then even not
technical like corporate acceptance. Here are some of the mod_lisp key
points: debugged, maintained, fast, reliable, stable, easy to setup and
Apache is a web server accepted everywhere by everybody. It's already not
obvious to make a webapp in Lisp for a big corp., you don't need to add
acceptance problems by bringing in an unknown web server.
Marc
From: Frank Buss
Subject: Re: Some feedback about the The Common Lisp Directory project. (And no, it's not in Python... ;-)
Date:
Message-ID: <wlt56abitfxl.11n6ngvng5lxz.dlg@40tude.net>
Marc Battyani wrote:
> In fact there are lots of reasons for mod_lisp, some of then even not
> technical like corporate acceptance. Here are some of the mod_lisp key
> points: debugged, maintained, fast, reliable, stable, easy to setup and
> Apache is a web server accepted everywhere by everybody. It's already not
> obvious to make a webapp in Lisp for a big corp., you don't need to add
> acceptance problems by bringing in an unknown web server.
I wonder why you add acceptance problems with a self-written Apache module.
I understand that it might be better to run Apache as an internet web
server in front of your Lisp applications, e.g. to filter out invalid
requests, provide static content etc. But looks like you've re-implemented
FastCGI:
http://cryp.to/publications/fastcgi/
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Marc Battyani
Subject: Re: Some feedback about the The Common Lisp Directory project. (And no, it's not in Python... ;-)
Date:
Message-ID: <dMOdnb8cDvTkQK3ZRVnyvQ@giganews.com>
Frank Buss" <··@frank-buss.de> wrote
> Marc Battyani wrote:
>
>> In fact there are lots of reasons for mod_lisp, some of then even not
>> technical like corporate acceptance. Here are some of the mod_lisp key
>> points: debugged, maintained, fast, reliable, stable, easy to setup and
>> Apache is a web server accepted everywhere by everybody. It's already not
>> obvious to make a webapp in Lisp for a big corp., you don't need to add
>> acceptance problems by bringing in an unknown web server.
>
> I wonder why you add acceptance problems with a self-written Apache
> module.
That's the contrary, nobody has any problem with an Apache module but almost
everybody is against non mainstream web servers.
> I understand that it might be better to run Apache as an internet web
> server in front of your Lisp applications, e.g. to filter out invalid
> requests, provide static content etc.
Almost all the Lisp servers are used that way anyway so they get the
disadvantages of mod_lisp without its advantages and are much slower.
> But looks like you've re-implemented
> FastCGI:
>
> http://cryp.to/publications/fastcgi/
mod_lisp is 6 years old now. So I don't know how is fastcgi now but at that
time mod_lisp was much simpler to use and faster and it has the great
advantage of being called mod_lisp.
There is no point to remake all the 6 years old debates...
For instance look at that cll thread
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/1dd73a5d2083a386/b91b4f67d42bc489?q=mod_lisp
It was started by Ari Johnson 2 years ago. Looks like he has not really made
much progress since then... ;-)
AFAIK mod_lisp is still the fastest, safest and easiest way to serve HTML
content behind an Apache server. You can even use several open source Lisp
application frameworks (TBNL, UCW, cl-modlisp, etc.) with it.
Marc
From: Jens Axel Søgaard
Subject: Re: Some feedback about the The Common Lisp Directory project. (And no, it's not in Python... ;-)
Date:
Message-ID: <4430e181$0$38669$edfadb0f@dread12.news.tele.dk>
Marc Battyani wrote:
> AFAIK mod_lisp is still the fastest, safest and easiest way to serve HTML
> content behind an Apache server. You can even use several open source Lisp
> application frameworks (TBNL, UCW, cl-modlisp, etc.) with it.
There are alternatives though. One option is to run the Lisp web-server
at a non-standard port and let Apache use mod_proxy to get the answer
from the Lisp web-server. Combined with mod_rewrite it is possible
to mix-and-match as you like.
I do know the solution is easy, but I am not knowledgeable enough
to say anything sensible about speed and security in this context.
<http://list.cs.brown.edu/pipermail/plt-scheme/2004-August/006471.html>
--
Jens Axel S�gaard
| There are alternatives though. One option is to run the Lisp
web-server
| at a non-standard port and let Apache use mod_proxy to get the answer
| from the Lisp web-server.
Unless your Lisp web server knows how to deal with HTTP/1.1 persistent
connections (which means either that it supports chunked encoding, or
that your application can calculate Content-Length headers on each
response before sending it - unusual for dynamic content), mod_proxy is
going to have to open a new socket to lisp for each request that it
proxies. Speedwise, mod_lisp's continuously open apache->lisp socket
is going to be a win over this behaviour.
On the other hand, the proxy cache in Apache is nice and simple to
configure, and depending on just how dynamic your dynamic content
actually is, you might win something back there if your application
sends correct Last-Modified and Expires headers. (Or not, if mod_lisp
has caching support these days. I haven't checked)
On Mon, 03 Apr 2006 10:32:26 +0200, Marc Battyani wrote:
> Frank Buss" <··@frank-buss.de> wrote
>> Marc Battyani wrote:
>>
>>> In fact there are lots of reasons for mod_lisp, some of then even not
>>> technical like corporate acceptance. Here are some of the mod_lisp key
>>> points: debugged, maintained, fast, reliable, stable, easy to setup and
>>> Apache is a web server accepted everywhere by everybody. It's already not
>>> obvious to make a webapp in Lisp for a big corp., you don't need to add
>>> acceptance problems by bringing in an unknown web server.
>>
>> I wonder why you add acceptance problems with a self-written Apache
>> module.
>
> That's the contrary, nobody has any problem with an Apache module but almost
> everybody is against non mainstream web servers.
Let me jump in here: that's exactly my experience as well: in corporate
world you can run the most crappy apache module (and, yes, there are a lot
of those) but even mention running a 'non-standard' webserver ...
I have both scenarios at the same customer, and, no matter why the Lisp-
only server has problems i get that "oh, it's _that_ server acting up ..."
looks i never get with a apache on drugs :-/
>> I understand that it might be better to run Apache as an internet web
>> server in front of your Lisp applications, e.g. to filter out invalid
>> requests, provide static content etc.
... hook into corporate authentication/authorization, click-tracking
modules, add-deliver etc. etc.
> Almost all the Lisp servers are used that way anyway so they get the
> disadvantages of mod_lisp without its advantages and are much slower.
>
>> But looks like you've re-implemented
>> FastCGI:
>>
>> http://cryp.to/publications/fastcgi/
>
> mod_lisp is 6 years old now. So I don't know how is fastcgi now but at
> that time mod_lisp was much simpler to use and faster and it has the
> great advantage of being called mod_lisp.
Also: mod_lisp was made for the needs of a Lisp backend. Hard to beat
with a general solution. I once had a pretty much working version of
mod_jk (the Apache maintained connector to Tomcat) for a Scheme
implementation - standard, yes, but not appropriate.
Cheers, Ralf Mattes
> There is no point to remake all the 6 years old debates... For instance
> look at that cll thread
> http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/1dd73a5d2083a386/b91b4f67d42bc489?q=mod_lisp
> It was started by Ari Johnson 2 years ago. Looks like he has not really
> made much progress since then... ;-)
>
> AFAIK mod_lisp is still the fastest, safest and easiest way to serve
> HTML content behind an Apache server. You can even use several open
> source Lisp application frameworks (TBNL, UCW, cl-modlisp, etc.) with
> it.
>
> Marc
From: drewc
Subject: Re: Some feedback about the The Common Lisp Directory project. (And no, it's not in Python... ;-)
Date:
Message-ID: <878xqkd5a6.fsf@rift.com>
"Marc Battyani" <·············@fractalconcept.com> writes:
> mod_lisp is 6 years old now. So I don't know how is fastcgi now but at that
> time mod_lisp was much simpler to use and faster and it has the great
> advantage of being called mod_lisp.
>
>
> There is no point to remake all the 6 years old debates... For
> instance look at that cll thread
> http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/1dd73a5d2083a386/b91b4f67d42bc489?q=mod_lisp
> It was started by Ari Johnson 2 years ago. Looks like he has not
> really made much progress since then... ;-)
>
> AFAIK mod_lisp is still the fastest, safest and easiest way to serve HTML
> content behind an Apache server. You can even use several open source Lisp
> application frameworks (TBNL, UCW, cl-modlisp, etc.) with it.
In fact, since that thread was posted, i've come full circle on the
mod_lisp issue. Although i don't use it for development, i've found
the opportunity to deliver under it and wouldn't have been able to
complete the project otherwise. There are non-technical issues that
must be realized (as you so nicely explained to me so many months
ago), and saying 'we can just use apache' has been a help ;)
mod_lisp is an excellent solution when you need apache, and has proven
itself quite reliable. Although i still prefer a lisp/thttpd/pound
solution where i have a choice, I find myself reaching for mod_lisp
more and more often as time progresses.
Thanks Marc!
drewc
> Marc
>
>
--
drewc at tech dot coop