[Web-SIG] Proposed WSGI extensions for asynchronous servers

[Ionel Maries Cristian]

On Mon, May 12, 2008 at 3:25 AM, Christopher Stawarz <cstawarz at csail.mit.edu>
wrote:

> On May 11, 2008, at 7:05 PM, Phillip J. Eby wrote:
>
>  For this to work, you're going to need this to take the wsgi.input object
> > as a parameter.  If you don't, then this will bypass middleware that
> > replaces wsgi.input.
> >
> > That is, you will need a way for this spec to support middleware that's
> > replacing wsgi.input, without the middleware knowing that this specification
> > exists.  In the worst case, it should detect the replaced input and give an
> > error or some response that lets the application know it won't really be
> > able to use the async feature.
> >
>
> I hadn't considered middleware that replaces wsgi.input.  Is there an
> example component you can point me to, just so I have something concrete to
> look at?
>
> Given that the semantics of wsgi.input are, in general, incompatible with
> non-blocking execution, I'm inclined to think that such middleware would
> either need to be rewritten to use x-wsgiorg.async.input, or just couldn't
> be used with asynchronous servers.  But I'll think about it some more --
> maybe there's a way to make this work.
>


Making input filters work could be achieved using greenlets - but then again
- if one would use greenlets he could use them to simulate a seemingly
blocking api for the input so this is pretty much pointless.

But I agree, detecting this is good and errors should be thrown in this
case.
In cogen i'm setting wsgi.input to None - so any use of it would end in a
error - though it's not very elegant.


-- 
http://ionelmc.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20080512/388db3ff/attachment-0001.htm>