mod_newlisp?

[stevegio]

Are there any plans to create a mod_newlisp or some other mechanism for using newlisp with Apache that avoids firing a new newlisp proc on every page invocation?  I'm very intrigued by newlisp but it would be difficult to build large scale apps without some kind of support like mod_perl, mod_python, or even mod_lisp.

[nigelbrown]

see discussion under ?mod_newlisp at http://www.alh.net/newlisp/phpbb/viewtopic.php?t=320&highlight=modlisp">http://www.alh.net/newlisp/phpbb/viewto ... ht=modlisp">http://www.alh.net/newlisp/phpbb/viewtopic.php?t=320&highlight=modlisp



Nigel

[Lutz]

I will look into it again after the next release (this week). It would be a mod_newlisp. Does anybody have pointers on how to write Apache modules besides the Apache docs itself?



Lutz

[stevegio]

see discussion under ?mod_newlisp at http://www.alh.net/newlisp/phpbb/viewtopic.php?t=320&highlight=modlisp">http://www.alh.net/newlisp/phpbb/viewto ... ht=modlisp">http://www.alh.net/newlisp/phpbb/viewtopic.php?t=320&highlight=modlisp



Nigel

Sorry, should have searched the forums.  I'll check thread out. Thanks.

[HPW]

>Does anybody have pointers on how to write Apache modules besides the Apache docs itself?



You can find Marc Battyani's mod_lisp-sources on his site:



http://www.fractalconcept.com">http://www.fractalconcept.com



When I remember some comments from him right, mod_lisp is not only usable for CL. But the source can give you more info I think.

[Lutz]

After studying the stuff about mod_lisp on http://www.fractalconcept.com">http://www.fractalconcept.com (link to mod_lisp is on their homepage) it seems to me that their Apache module is perfectly usable for newLISP, or any other programming language, which can communicate via sockets.



The only thing we need is some kind of 'apache_mod.lsp' written in newLISP, which sets newLISP up for listening to key<->value pairs from Apache and sending them back. The whole module could be written in probably less than a page of code.



Loading of 'apache_mod.lsp' into newLISP would start newLISP as a server waiting for requests from Apache.



For each request coming from the Apache mod_lisp module, newLISP would start a new thread handling over the key<->value pairs from Apache for processing. There sems to be nothing LISP-specific in their mod_lisp!?



I am still not sure what is gained byt this, is it that socket communications with Apache would be faster than the normal CGI / stdio way of doing it? Or is it the fact that newLISP already would be running and save startup-time?



If the latter one is the reason (start-up time), then I don;t think its worth while, considering the extreme fast start-up time of newLISP.



I wonder if anybody here has experience with mod_perl, mod_python or mod_php and can tell what advantages it brings or not.



Lutz

[stevegio]

I wonder if anybody here has experience with mod_perl, mod_python or mod_php and can tell what advantages it brings or not.

Lutz

Even though newLisp has a very quick startup, It's expensive, from an operating system point of view,  to constantly start a new newLisp process for each request. For very low traffic applications forking a new process to run a CGI is probably not a big deal but once you start talking real world scenarios the expense of starting a new process for every request becomes a real problem. This is an old problem and that is why things like FastCGI, mod_{perl|python|lisp} exist.  <a href="http://www.fastcgi.com/devkit/doc/fastcgi-whitepaper/fastcgi.htm%22%3EHere%3C/a">http://www.fastcgi.com/devkit/doc/fastc ... m">Here</a">http://www.fastcgi.com/devkit/doc/fastcgi-whitepaper/fastcgi.htm">Here</a> is a pointer to the old FastCGI white paper.  If it's easy to put this together I'd suggest putting it on your development roadmap.  Serious web developers will probably appreciate it. I've been hacking around with newLisp and it shows a lot of promise, if not down right power. However you couldn't use newLisp for anything that had high volume traffic if it uses old-style CGI.  It just won't scale no matter how fast it starts up.[/url]

[Excalibor]

...



I am still not sure what is gained byt this, is it that socket communications with Apache would be faster than the normal CGI / stdio way of doing it? Or is it the fact that newLISP already would be running and save startup-time?



If the latter one is the reason (start-up time), then I don;t think its worth while, considering the extreme fast start-up time of newLISP.



I wonder if anybody here has experience with mod_perl, mod_python or mod_php and can tell what advantages it brings or not.



Lutz

There are many other benefits by having a mod_newlisp, if done properly. It's not just any speed improvement, but also the possibility of working in the server memory pools, which allows session management in-memory, and many other niceties like accessing the previous page request object, etc... (à la Apache::Registry, etc...)



It's been a while since I last fought with Apache modules, but mod_perl allows you to access via hooks to the complete server interaction cycle, and thus allowing a lot of things that are plainly nifty; it would be a great thing for newlisp; I am sure, however, that it is something very involved, exposing different objects/interfaces/contexts to newlisp so it can work directly with the request and the response at all levels, but there's an easy starting point and the module can grow from there...



best regards,

david

[Lutz]

Thanks Stevegio and David for the pointers and suggestions, sounds like a more involved topic. May be the exisiting mod_lisp is too simple, although probably a good start, they (Fractal concepts) report big speed gains using it. One of the key things seems to be that newLISP is always running and is able to keep state for different sessions.



Most of the work would probably be writing newLISP code. I will study the web pointers about Perl/Pyton and FastCGI. One of the things to explore would be, if the task also involves writing a new newlisp_mod or if one of the existing modules could be used/modified for newLISP.



Lutz

[lwix]

Hi I'm new -- thank you for new newLisp. I like the fact that newLisp is small and efficient.



I am a student and web developer soon to be undertaking web-development projects for non-profit organisations.  These organisations have only low-powered computers with little memory.



In reference to mod_newLisp, I suggest that Lutz not spend time (at this stage) implementing it.  It takes a very long time to get it right and stable.  Lua have been working on this for more than a year without a release yet --

       http://www.keplerproject.org/">http://www.keplerproject.org/

and /they/ have funding and (several developers) just for this purpose.



There is a more immediate and attractive solution to the expense of forking a new interpreter for each cgi process.  And that is use newLisp httpd with newLisp cgi scripts (and newLisp sqlite).  Of course we can do this now but what I am suggesting is to improve what we have. e.g. we can implement cookie handling in httpd to begin with.



The idea, of course, is not new and has long been popular in tcl.  Please see:

     http://www.tcl.tk/software/tclhttpd/">http://www.tcl.tk/software/tclhttpd/



This solution is quite workable for low to medium sites.  And I suggest that this is where newLisp will first be used.  newLisp should not go after big sites yet, start small and grow (as Linus says in a recent interview).



Thanks again.



-- Lucas

[Lutz]

Hi Lucas, welcome to the newLISP discussion group.



Yes, at the moment I will not spend time on a mod_newlisp. I did some benchmarks, which suggest, that the need for a Apache module in newLISP is not urgent. Speed of normal CGI with newLISP is competetive with Apache+mode_perl. But that doesn't mean that newLISP Apache performance couldn't be improved with a mod_lisp, and therefore it's on my list of things to do, but not with high priority



Lutz

[HPW]

Reposted from comp.lang.lisp:

Von:Marc Battyani (Marc.Battyani@fractalconcept.com)

Betrifft:[ANNOUNCE] mod_lisp2 1.0

 

The long awaited mod_lisp2 for Apache2 is available.



mod_lisp2/1.0 is on the mod_lisp repository:

http://www.fractalconcept.com:8000/public/open-source/mod_lisp">http://www.fractalconcept.com:8000/publ ... e/mod_lisp">http://www.fractalconcept.com:8000/public/open-source/mod_lisp



There is also a tarball of the current repository here:

http://www.fractalconcept.com/download/mod_lisp-current.tgz">http://www.fractalconcept.com/download/ ... urrent.tgz">http://www.fractalconcept.com/download/mod_lisp-current.tgz



(Thanks to Edi Weitz who pushed me to finish it.)



Marc

[Lutz]

Thanks Hans-Peter, the protocol to communicate with Apache mod_lisp (mod_lisp.c, mod_lisp2.c) is quite simple.



The example programs for various Common Lisps are all between 100 and 200 lines only and could probably be done in 50 lines or less in newLISP. It is basically setting up a simple server to do the mod_lisp protocol sending receiving data on port 3000.



At the moment this is low on my list of priorities but will happen one day, if nobody else does it.



Lutz

[HPW]

Latest announcement:

Here are the latest modifs for mod_lisp/mod_lisp2:



mod_lisp: Case insensitive parsing of the lisp header names for

compatibility with mod_lisp2



mod_lisp2: Fixed lisp_handler to allow for no Content-Length header [Tim

Howe]



mod_lisp is on the mod_lisp repository:

http://www.fractalconcept.com:8000/public/open-source/mod_lisp">http://www.fractalconcept.com:8000/publ ... e/mod_lisp">http://www.fractalconcept.com:8000/public/open-source/mod_lisp



There is also a tarball of the current repository here:

http://www.fractalconcept.com/download/mod_lisp-current.tgz">http://www.fractalconcept.com/download/ ... urrent.tgz">http://www.fractalconcept.com/download/mod_lisp-current.tgz



Marc

[HPW]

mod_lisp version 2.41 is on the mod_lisp repository:

http://www.fractalconcept.com:8000/public/open-source/mod_lisp">http://www.fractalconcept.com:8000/publ ... e/mod_lisp">http://www.fractalconcept.com:8000/public/open-source/mod_lisp



Version 2.41

 Case insensitive version of the set-cookie



 Version 2.40

 Allow more than one Set-Cookie

 (it was in 2.2 but was wrongly removed in 2.35)



 Version 2.39

 Case insensitive parsing of the Lisp header names for compatibility with

mod_lisp2.



Marc