-> > I spent some time today bashing on a rewrite of the PyWX adapter for
-> > Webware (which none of you have ever seen, anyway ;). I have some
-> > questions for y'all.
-> > Some background: PyWX is an embedding of Python in AOLserver, a
-> > high-performance multi-threaded Web server. The goal of the PyWX
-> > adapter for Webware is to run an actual ApplicationServer inside of
-> > PyWX, so that you avoid the latencies of communicating with the
-> > AppServer.
-> > The main code is below. This code goes in a file that is imported
-> > once, at the start of the Web server; 'handle' is called once for
-> > every connection under '/w/' on the server.
-> There is no other 'format' other than 'CGI'. But we could always add
-> one if motivated. However, web servers seem to always have that kind of
-> function you used:
Well, in this case I had to adapt the function, which is part of PyWX,
but I know what you mean -- CGI is quite common. Unfortunately, *exactly*
what goes into the CGI environment is a bit less clear; I guess "just stick
with what Apache does" is the way to go.
-> But regarding putting the app server in the web server:
-> One of the biggest features I implicitly use in Webware is the ability
-> to restart the app server with no interruption to my users.
-> This is accomplished because of 2 things.
-> First, the web server and app server are typically separate processes,
-> so the web server can stay up even if the app server is not.
-> Second, the various adapters for WebKit (that live in the web server)
-> will timeout after X seconds, but retry Y times before giving up on the
-> app server. I forget what the default X and Y values are; I've never
-> had to tweak them.
[ munch ]
-> And all that users notice is that requests took a few seconds longer
-> than usual (and the bug I just fixed is gone).
-> If the app server lived in the web server, then users would more likely
-> notice "Cannot connect" messages, although I don't know for sure how it
-> would go, because I've never tried that approach.
If you have a somewhat busy Web server (more than 1 req/s) one or two people
would probably get a "no connection" message, true. Although once you got
to the point where you had to be concerned about scalability, fixing bugs
on the live site sounds a bit daring to me ;).
I did "port" (a basic code swipe from WebKit.cgi) the CGIAdapter into
PyWX, so that you could trivially replicate in AOLserver the Apache approach.
It's probably about as fast as mod_webkit, and it's probably much
more scalable (because of those ugly Apache process/thread distinctions).
It doesn't sound like speed is much of a concern, though.
Incidentally, for the PyWX out-of-process adapter I wouldn't have to change
a single piece of code, were CGIAdapter a bit more flexible about accepting
in/out arguments (rather than assuming sys.stdin/sys.stdout). Would you mind
if I went in and added this flexibility (i.e. does it seem like a bad thing