[Twisted-web] Re: [Web-SIG] WSGI woes

[Alan Kennedy]

[Alan Kennedy]
>> When I described your approach as "pulling data up the stack", I saw a 
>> bigger difference between the two approaches. I'm thinking now that 
>> there is little difference between our proposals, except that in mine 
>> it's the bottom component that gets notified of the input by the 
>> server, and in yours it's the top component. Though I suppose having 
>> the top component pulling input from an iterator chain mirrors nicely 
>> the situation where the server pulls output from an iterator chain.

[Phillip J. Eby]
> Actually, I'm saying you pull data *down* the stack.  The bottom-most 
> application iterator calls 'read()' on an input stream provided by a 
> parent middleware component, which then calls read on a higher-level 
> component, and so on.

Hmm. That only makes sense to me if your stacks grow downwards :-)

In my mental picture, stacks grow upwards. The server is level ground, 
and each middleware component is placed on top of the other, with the 
"most wrapped" component at the top.

So to me what your description above says is that the component closest 
to the server is the one that gets to see the input last, after all the 
more wrapped components, with the most wrapped component getting first 
dibs on the input. Which doesn't make sense to me.

Perhaps your stacks grow downwards?

Anyway, I *think* we're talking about the same thing.

Which leads onto the next question: Why not insist on an iterable for 
the input stream as well as the output stream. It appears to me that 
there should be symmetry between the output write()/iterable split and 
the input read()/iterable split.

Regards,

Alan.