[Web-SIG] Latest WSGI Draft

[Phillip J. Eby]

At 12:24 AM 8/23/04 -0500, Ian Bicking wrote:
>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.

Really?  I thought you were asking for something to be called upon exit as 
a way of addressing this exact same issue: i.e., the app knowing when to 
clean up after itself.


>   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.

Fine.  I just don't like it being anything other than a heuristic.  Suppose 
I'm running acceptance tests?  My CGI runner will say "you're being run 
only once", except then I'll run it again when the acceptance test tests 
another input.  But, I want the acceptance test to test the operation of 
the application when it's in "cgi mode", effectively.

So, what I'm saying is that any app that I wrote, I would want 'run_once' 
or 'last_run' or whatever it was called to *not* be a guarantee of never 
running again, but only a suggestion to "rig for infrequent running".  If 
my code *actually* relied upon it being a guarantee, then testing scenarios 
are hosed.


>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.

Really?  Why not?  Let's say that mod_python provides the function, the app 
calls it, doesn't call 'start_response', and doesn't return an 
iterator.  What does middleware do?  Well, presumably it does 
nothing.  Definitely it does nothing if it's an output transformer, or if 
it just adds things to the request.  So, where's the problem?

For other kinds of responses, the behavior is as I outlined before: if the 
extension is replacing the existing functionality, one should have to call 
a function to get it, passing in the existing functionality (e.g. environ 
or start_response) so that the extender can verify that critical functions 
aren't being mediated by middleware.


>>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.

Alas, that's all too true.  :(