[Web-SIG] WSGI uses

[Phillip J. Eby]

At 12:37 PM 8/19/04 -0700, tony at lownds.com wrote:
> > For instance, I was thinking about setting up something for Medusa with
> > WSGI.  But though I think asynchronous code seems like a good server
> > architecture, I'm not that interested in it for applications.  But this
> > iteration of the WSGI spec allows for async pretty well; you can tell
> > you are in that situation when wsgi.multiprocess is false and
> > wsgi.multithread is false, and the iterator output can produce the data
> > fairly well.
> >
>
>How do you decide when to actually send the data back to the client? On
>every yield?

That's up to the server to decide.


>In a similar vein, if servers/gateways send data back on every call to
>write, and applications don't take that into account, they could also
>suffer in performance. It seems like an object with write() and flush()
>makes it easier to provide guarantees about streaming -- which I think
>WSGI ought to do.

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.


> > I then realized that threading itself could be a piece of middleware --
> > you just have to do the proper buffering with input and output.  An
> > intelligent application that realizes it can't run as an async process
> > could install this middleware itself when necessary.
> >
>
>Did you find that an async server has to provide a new buffer for every
>request to implement the write() function correctly?

I'm not sure I'm following either you or Ian here.


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


>For instance, having one method to start the response and NOT get a
>write() function could allow server/gateways avoid some work...

In order to be compliant, the server *must* support the write() facility, 
so there's no point to making it optional.


>What about passing in a class with class methods in place of the
>start_response method? i.e.
>
>class ContextLogic:
>     @classmethod
>     ....
>
>Contexts can be re-used, and middleware does not have to delegate (it just
>subclasses on the fly).

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.

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.


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