[Web-SIG] WSGI 2.0

[Phillip J. Eby]

At 07:38 PM 10/5/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > I still don't see how this is *useful*.  What will the application *do*
> > with this information?
>
>As an example (not tested) SQLAlchemy can implements a
>RequestSingletonPool, that is the equivalend of ThreadSingetonPool.
>
>In this case the pool will checkout a connection using the
>environ['wsgi.request_id'] identifier (unique for each request), instead
>of thread.get_ident.

I still don't see the point of this.  Why can't the application just 
keep a reference to the connection object it's using?  That doesn't 
require any new code and already works now in every existing WSGI 
server.  Why write code that is more complex to do something that you 
don't even need?

Not only that, but the ONLY reasons for the application to yield are 
if it's sending something too big to fit in memory, or it's doing 
server push (or otherwise wants to stream the content).

Such applications are extremely rare to begin with, or should be.  If 
you are seeing applications that yield multiple strings and *aren't* 
one of these use cases, it indicates that the application author 
doesn't understand the WSGI spec, and doesn't realize they're slowing 
down their application by doing it.  Yields are for streaming, and 
most web applications shouldn't be streaming.

That means that 99.9% of all WSGI applications should never produce 
more than one output string -- which means that the "interleaving" 
question never even comes up.  The applications that produce multiple 
output strings have to deal with the complexity of the situation anyway.