[Web-SIG] PEP 444 (aka Web3)

[Robert Brewer]

Marcel Hellkamp wrote:
> Am Donnerstag, den 16.09.2010, 22:58 +0200 schrieb Armin Ronacher:
> > - The async part.
> > If I can't find someone that is willing to provide some input on that
> > I will remove that section.
> 
> I see a problem here: The response tuple must be returned synchronously
> according to web3. Once returned, the values are final. If an
> application needs to wait for some background task to finish in order
> to decide about headers or the status code, it is now forced to block
> completely.
> 
> A common use case for this is a web service that itself queries other
> web services (e.g. an ajax proxy to work around "same origin policy").
> 
> 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 do understand that the start_response callable is inconvenient for
> middleware to implement, but it totally made sense.

I don't follow. What is the benefit of yielding empty strings instead of just waiting for the status and headers to be available? Do you then run off and do other things with that server thread?

I've run a few businesses now on WSGI without doing what you describe, so I don't see why blocking makes an application 'trivial'.


Robert Brewer
fumanchu at aminus.org