[Web-SIG] WSGI uses

[Phillip J. Eby]

At 02:33 PM 8/19/04 -0700, tony at lownds.com wrote:
>[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?

I don't see what you mean about buffering.  As for it being a second-class 
citizen, it certainly is.  But application frameworks that currently 
provide some analogue to write() in their API today, can't live without 
it.  So, the write() functionality has to be there or WSGI is DOA.



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

What would this "more powerful API" consist of?  WSGI is a paper-thin 
abstraction of HTTP; that's its sole purpose.



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

I've written a prototype WSGI server based on the previous draft: all it 
does is serve WSGI apps, so there's no "driver" involved.  I expect there 
will be other such fully-integrated servers.  A CGI-based gateway also 
isn't *part* of the server it runs under, so it's a gateway, not a 
driver.  Thus, it seems to me there are only servers and gateways.  That 
some gateways may be implemented as a driver within a server seems like 
obscuring the *purpose* of the API (allowing an application to run in a 
server or a gateway thereto) in favor of an implementation detail that 
doesn't even always apply.