I don't like this proposal at all. Besides having to go through the bytes craziness the design is pretty backwards for middleware and asynchronous applications.
Even the proxy_and_timing_support example in the PEP is broken for async or streaming apps - it won't return the proper time (since it doesn't consume the body iterable) and it will fail most of the times since you can't just add a tuple to a iterable. The missing requirement that middleware must yield at least an empty string if they need more more information from the application iterable also breaks async gateways that expect oob information from the app (for example cogen can't be ported to this spec). The removed requirement "middleware components *must not* block iteration waiting for multiple values from an application iterable. If the middleware needs to accumulate more data from the application before it can produce any output, it *must* yield an empty string." also breaks async gateways/apps. I feel this spec puts too much burden on applications - having to process all those byte strings and even having to add Content-Length even for naive buffered-body apps. --ionel On Thu, Sep 16, 2010 at 02:03, Chris McDonough <chr...@plope.com> wrote: > A PEP was submitted and accepted today for a WSGI successor protocol > named Web3: > > http://python.org/dev/peps/pep-0444/ > > I'd encourage other folks to suggest improvements to that spec or to > submit a competing spec, so we can get WSGI-on-Python3 settled soon. > > - C > > > _______________________________________________ > 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/ionel.mc%40gmail.com >
_______________________________________________ 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
