On 12/17/2010 1:20 PM, Zach Beane wrote:
For example, you could have a HTTP handler that accepts POST requests and takes a parameter as Lisp code to read with e.g. READ-FROM-STRING, evaluate with EVAL and return the result with e.g. PRINT-TO-STRING.
We do something like this. For lisp websites my company makes, we have a password-protected admin section with some light UI to help us manage the site (turn logging levels up/down, clear caches, etc), and one of those tools is a "evaluate this code in the running lisp" textarea, with a dropdown to select what package it runs in. This is very rarely used to patch the site in emergency situations or for trivial changes where we don't want to bring down the site. This has bit us a few times, where we fixed a small bug directly in the running lisp and then forgot to publish the new code and had mystery regressions when the lisp process was restarted.
While having a long-running process on the server is appealing, we decided to spend our engineering time on making the lisp process easy to start, stop, restart, and deploy.
Personally, doing a lot of direct patching to a production system scares me. I worry about introducing bugs/hidden dependencies that wouldn't be represented in source code, and getting conflicts between multiple developers updating the same lisp.
Eventually the server is going to need a reboot or a have a hardware failure, and I want to have utmost confidence that my program will: 1) behave the same after a restart 2) behave the same when I deploy from source to another server
For development, we do run use swank over SSH tunnels, and run one copy of the website per developer.
Thanks,