Ian Bicking wrote: > Jim Fulton wrote: ... >> Why do I want this? It appears that this would be needed to enable >> middleware components that manage application threads. I can imagine >> though that there aren't any existing servers that handle what I've >> suggested correctly. >> >> I do think it would be straightforward for servers to handle this >> correctly, especially for asynchronous servers like Twisted >> and ayncore-based servers. Perhaps this could be an optional feature >> of the servers. Servers supporting this feature would be prepared to >> delay response output until start_response is called. Servers unable >> to do this would generate errors if start_response hasn't been called >> by the time the result iterator has been constructed. > > > I suppose this wouldn't be particularly bad for threaded or multiprocess > servers either -- they use a thread/process until the request is > completed regardless of what happens.
Exacept that it makes the implementation a bit more complex. > I can see how it could be used to > greater effect in an asynchronous server. However, I'd rather it not be > optional, as most WSGI apps won't do this, and so servers won't get good > testing on this or may just not implement it, and then some apps and > some servers won't be compatible. I mostly agree, except that I think this feature may only be useful for asynchronous servers. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ 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
