On Apr 28, 2005, at 2:02 PM, Ian Bicking wrote: <What I want in a WSGI server>
twisted.web2 supports: HTTP, HTTPS, CGI, and I wrote SCGI yesterday and will commit it this weekend. FastCGI looks like a complicated protocol, so it'll probably be a bit harder than SCGI to implement. Is there actually a reason to support it as well as SCGI?
While FastCGI isn't defined as having layers, I'd kind of treat it like that. From what I can tell, it's like SCGI with a stderr stream...? Other parts could probably be ignored. The advantage is that it's more widely supported/installed. I think, kind of. For example, lighthttpd has built-in FastCGI support. But then I bet it would be easy to convince them to include SCGI too.
Right now, web2 runs WSGI apps in threads. It'd be possible to write a wrapper that runs them in their own processes, too, but would that give any advantage vs the simple CGI->WSGI wrapper that already exists? You can just use web2's ability to run CGIs to run WSGI-in-separate-processes also.
Well, the possible advantages:
* Fork instead of spawn a process, so as to save startup time. Not possible on Windows.
* Reuse processes, so as to save startup time. Possible on Windows, I think. Though they went through all of that trouble in Apache 2 (and even some weird fork of 1.3) to make it threaded, so maybe there's something I don't know.
But I feel fuzzy on the details, so maybe some of this is a wash. Could you just run, say, ten non-threaded Twisted servers, and have the main server delegate a request via SCGI to one of those subservers? Is it acceptable for a Twisted server to block if you aren't serving concurrent requests? I don't do enough multiprocess programming to speak intelligently on some of this.
It is my desire to enable twisted.web2 to be used to host any application in any environment, by providing a number of different deployment options and app running options.
I've been developing it somewhat under the radar, but It's getting to the point where it's fairly stable. At this point the major TODO is sitting down and writing some documentation, so I'll try to get an alpha release out soon.
One advantage of WSGI is that you don't need to document it. You'd still have to document server invocation and some other details, but lots of things people think of as part of the server needn't be (e.g., name-based virtual hosting). People who plan to do async programming under twisted.web2 probably need much more information about the internals, but WSGI users only need to know you Do The Right Thing (not how you do it).
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
