<wrt being able to yield an empty string repeatedly until the application has time to generate a response tuple as a fundamental in an async web framework>
On Sat, 2010-09-18 at 14:08 +0300, Ionel Maries Cristian wrote: > There's a framework called cogen and it relies on this policy. I've been told by a number of people (both async and sync people) that WSGI is a poor protocol on top of which to develop async applications, and they usually go on to say that async applications and servers really should communicate over separate (perhaps-WSGI-like) protocol. I don't really know much about developing async web applications, but frankly I'm loath to keep features in this thing that are only tolerated (spat upon lightly! ;-)) by async folks, but which are also common tripping points for people who never write async applications. This is an apologetic way of saying "please find more champions for this feature". - C > > -- ionel > > On Sat, Sep 18, 2010 at 12:34, Ian Bicking <i...@colorstudy.com> > wrote: > On Sat, Sep 18, 2010 at 5:03 AM, Marcel Hellkamp > <m...@gsites.de> wrote: > > With WSGI it was possible to yield empty strings as > long as the > application is waiting for data and call > start_response once the headers > are final. Not perfect, but at least non-blocking. > Web3 removes this > possibility. The headers must be returned before the > body iterable > yielded its first element, empty or not. > > Removing any support for this type of asynchronism > would render web3 > useless for all but completely synchronous and trivial > applications. > Even frameworks would have no way to work around this > anymore. > > I'm aware of what a lot of people have done with WSGI, but I'm > not aware of anyone doing an async proxy of any sort, or > implementing anything in a way where this empty string policy > served any function. It's not implausible that it *could* be > used, but years of practice have shown it is not used. > > > > -- > Ian Bicking | 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/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/chrism%40plope.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