[Web-SIG] Latest WSGI Draft

[Ian Bicking]

Phillip J. Eby wrote:
> At 05:41 PM 8/22/04 -0500, Ian Bicking wrote:
> 
>> Phillip J. Eby wrote:
>>
>>> Alright.  Let's make it 'wsgi.run_once'.  Here's my attempt at a 
>>> shorter explanation:
>>> ``wsgi.run_once``      This value should be true if the server/gateway
>>>                        expects (but does not guarantee!) that the
>>>                        application will only be invoked this one time
>>>                        during the life of its containing process.
>>>                        Normally, this will only be true for a gateway
>>>                        based on CGI (or something similar).
>>
>>
>> Is there a reason it can't be guaranteed?
> 
> 
> Is there a reason it *should* be guaranteed?  :)  The last time we had 
> this discussion (December?), I thought you'd decided that the standard 
> library's "atexit" facility was sufficient to cover your use case if a 
> guarantee was needed here.  (I only just remembered the "atexit" 
> discussion, or I'd have suggested that as the solution instead of 
> introducing 'wsgi.last_call' a few days ago.)

atexit was a different discussion.  I don't know if there's a reason it 
should be guaranteed, but then I don't know if there's any situation 
where it wouldn't be guaranteed.  I can't imagine it being used outside 
of a CGI context, and it is guaranteed for CGI.

> Actually, there's another way to handle this.  Suppose we put the burden 
> on server authors to provide safe extensions?  Specifically, if a server 
> provides an extension that can be used in place of, or as an extension 
> to, any native WSGI facility (request data, response management, 
> environment, etc.), then that facility *must* respect any changes made 
> by middleware, or generate an appropriate error.
> 
> An example would be that if mod_python wanted to supply its request 
> object as an extension, it would have to supply a variable like 
> 'mod_python.get_request', which would be a callable taking 'environ' and 
> 'start_response'.  If any 'environ' contents supplied by mod_python had 
> changed, or 'start_response' wasn't the 'start_response' it gave to the 
> application, it would have to either provide an alternative object, or 
> raise an error, or return None, or something of that sort.  In other 
> words, the burden of verification is on the extender.

I can see that working for extensions to the request, but what about 
extensions to the response?  E.g., some mod_python extension could allow 
for internal redirects -- a useful feature that won't fit into WSGI. 
There's nothing the extension could do to check for middleware that 
would be interested, as the middleware that's interested is going to 
modify the output, not the request.

> This would simplify the spec somewhat, since we wouldn't need to 
> introduce 'wsgi.extensions', and we can also drop the suggestion for 
> middleware authors to delete extensions.  Middleware is simpler too, it 
> just changes what it needs to and moves on with life.  :)  We would just 
> have to add a section on how to build "safe" extensions to the spec.

I do like the idea of simplifying this part of the spec.  If it works. 
It's also something people can work out on their own.  I expect the vast 
majority of these servers and applications to be open source, and if 
some pieces don't work together at first there's a feedback loop to fix 
that.

Also, I don't think any of these discussions need to be resolved before 
this becomes a real PEP.  There's going to be more discussion then (no 
matter how much we discuss now), and this discussion can just be part of 
that process.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org