> Having a HTTP 1.0/1.1-compliant production-grade > WSGI-only server in the distro would be sweet :-) > > I might be demanding a bit much here, but still ...
To "demand" it might be a bit much, but to "expect" it...? ;) I don't think anyone's going to drop what they're doing and go code such a server because it's been demanded; even if they did, it would need a long-ish period of time in which it was tested by the community in production scenarios. However, since our hypothetical server is not yet in the standard library, who would use it in production? Catch-22. An alternative would be to allow one or more of the servers which have been written for CherryPy or Django to see some use "in the wild", and have each go through its own series of bugfixes and performance improvements, driven by direct need. When they have done so, we can compare them and drop one into the standard library with far fewer unknowns. I'm obviously biased (being on the CherryPy team), but I think the "winner" will be Peter Hunt's WSGI server for CherryPy. It was designed from the beginning to be framework-agnostic; that is, there's nothing CherryPy-specific in the module. Peter has said multiple times that he'd like it to become the standard WSGI server, and that his desire is for other frameworks to adopt it wholesale. Django should certainly grab it right away; performance-wise, it beats the pants off the reference server that comes with wsgiref (which is what they based their WSGI server on). If there are any licensing or other issues keeping django from using the CherryPy WSGI server, swing by irc://irc.oftc.net/cherrypy and we'll get them worked out in a hurry. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list