[Web-SIG] WSGI uses

[tony at lownds.com]

[Phillip]
> If you need to avoid creating data before the client is ready for it, you
> should use the async interface (yielding data) rather than the push
> interface (write() calls).  An asynchronous server should avoid moving the
> iterator forward when the outgoing socket isn't ready for data to be sent.
>

The use case I had in mind was the application sending a partial response,
then doing a lot of work, then sending the rest of the response. I guess
you are saying that WSGI apps shouldn't use write() in that case. I wonder
when they should use write() then. If it's a second class citizen to the
iterator why not force all applications to provide their own buffering?

>>Although I suggested the (env, start_response) -> write() protocol, it
>>just can't adapt to future needs. As soon as more than one
>> function/method
>>is needed, the API is broken -- and can't be fixed.
>
> Actually, there are several extension routes available, such as adding
> optional or keyword parameters to start_response() and write().
>

True. Thats less than elegant though.

>>What about passing in a class with class methods in place of the
>>start_response method? i.e.
>
> Interesting concept, although it means that servers would also be
> subclassing on-the-fly if they need per-request data on the
> context.  Though I suppose all methods could be required to take the
> environment as a parameter.
>

Yes, all methods would need take env.

> So far, I'm -0.5 on the idea, as I'd *really* like to keep the whole thing
> super-minimalistic.  Everything that expands the scope increases the range
> of ways that people can accidentally write implementations that don't
> interoperate.
>

It just seems too minimal. It's hard to see how a server could cleanly
implement a more powerful API than WSGI 1.0 and still be backwards
compatible with apps/frameworks that use the WSGI 1.0 interface.

>
>>One more thought: how about using the term WSGI "driver" instead of
>>server/gateway?
>
> But servers and gateways are what they *are*.  They're not "drivers" in
> any
> sense that I understand, at least.
>

The way I see it, server is apache, or mod_python -- there would be a
piece of code that implements the WSGI interface on top of the server.
That's the driver.

-Tony