There is a new responder of interest:
The browser responder has also been overhauled and now shows word documentation:
The help and browser responders still have a few wrinkles. Once they're sorted out, and if I'm happy with the stability of the test server, I will make it the primary server.
The web site has seen 10,000 hits over the last 10 days. To date I haven't had a single issue with the Factor HTTP server. It is not a huge load, but it looks like the server is working okay.
I should mention my workflow when writing web code in Factor. I develop web apps locally on my workstation. I have the jEdit plugin run a Factor instance. I start the HTTP server in this instance, and while working on a responder, reload the source files with a jEdit command and immediately test the changes.
When I'm ready, I copy a bootstrapped image with the HTTP server loaded to my Linode box. On the Linode server, the Factor HTTP server runs inside a detached 'screen' instance. I can log in to the server, run
screen -r, and I'm looking at the Factor listener. I can reload code and inspect server objects, all without restarting or 'redeploying' anything.
Being able to reload code in a running server without downtime is important. Look at the Java situation:
Here's the situation. I have a project that runs in JBoss. In normal/non-debug JBoss takes about a minute to startup and get ready to receive requests. In debug mode we're talking 2.5-3 minutes to startup even when no debugger has been attached. Given the severe difference in startup time I tend not to run the server in debug mode until I really really need to debug something. But then if I need to make a change and restart the server (hot-deploy and redeploy do not cover nearly enough) it's frustratingly slow!