> Anything that could be considered of sufficiently industrial strength > to be secure and scalable in production would necessarily be such a > large project, such a complex code base, and have such different > release cycle that it would not make a good standard library > candidate. (Think mod_python, Twisted, Zope, Apache; think tail > wagging the doc.)
I was thinking into products that have shown good results over the last past year and are far less complex than the ones you mention. There are existing implementations that could be easily extracted from their environment and might be better: CherryPy, Paste, Pylons, Colubrid, etc. all offer what wsgiref provides (well to what I understand from wsgiref code, Phillip could correct my knowledge here). Nevertheless, it might be more useful to define the boundaries of including a WSGI implementation to the stdlib before even choosing one. AFAIK, WSGI is splitted into three distinct layers. A web server Some middlewares An application We will not include middlewares I believe. I'm not sure I would see the point of adding a default WSGI application. So we're left with the web server part to test and then see which is the one filling the best the criteria folks around here may decide to discriminate on. - Sylvain _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
