-> > 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: -> ns_setup.create_cgi_environ()
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 to have)? cheers, --titus _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
