[Web-SIG] Getting back to WSGI grass roots.

[René Dudfield]

On Wed, Sep 23, 2009 at 1:03 PM, Aaron Watters <arw1961 at yahoo.com> wrote:
>
>
> --- On Wed, 9/23/09, Graham Dumpleton <graham.dumpleton at gmail.com> wrote:
>
>
>> So, rather than throw away completely the idea of bytes
>> everywhere,
>> and rewrite the WSGI specification, we could instead say
>> that the
>> existing conceptual idea of WSGI 1.0 is still valid, and
>> just build on
>> top of it a translation interface to present that as
>> unicode.
>
> Seconded.  There should be a lower level that talks bytes
> and a higher level that talks unicode or whatever.
> There should also be a way for
> even higher levels to reach down
> to the lower level to see the bytes before they got
> misdecoded by the unicode layer because this will
> likely be needed in some cases.  Is there anything
> wrong with just adding decoded interpretations to
> the WSGI environment as separate entries?
>
> Also, everything should be as orthogonal as possible.
> One problem I have with most Web tools and frameworks
> is they tend to take over and do everything at once
> when I really only want a little bit of help.  WSGI 1
> is nice because it just abstracts HTTP and stops there.
> It was a beautiful piece of work.  Kudos.
>

Yeah, wsgi is definitely useful for a wide range of uses cases.

Except it's currently not working for a number of use cases... but we
can't accommodate them.  eg, unicode, tainting, http proxies, http
clients, user supplied buffers, async, latest http RFCs, different
uses of http compared to 2003, all features of http.  This is clear by
the variety of web frameworks that don't use wsgi, and the variety of
things layered on top of wsgi.

There's room for other specifications which consider those use cases
not covered by wsgi. http proxies cover the main wsgi use case of
being able to use applications on many servers(apache, nginx lighttpd
etc) .  Things like webob, and cherrypy allow python frameworks to
coordinate at a higher level avoiding wsgi as well.

It's also clear that async frameworks can be used with wsgi in a non
blocking manner given things like the greenlets/stackless and the
Eventlet library - which makes use of two underlying async
frameworks(twisted, and libevent) given that all of your blocking
calls to libraries can be swapped out with versions written for
async... like many have already(eg you can use a urllib api like
library).

We have to keep remembering what the purpose of wsgi is.  Opening line
of wsgi spec: "This document specifies a proposed standard interface
between web servers and Python web applications or frameworks, to
promote web application portability across a variety of web servers."
By limiting its scope we do get something useful out of it(for some
people).

Application portability is the main wsgi use case.  I think that
requires a number of things that wsgi doesn't provide - wsgi knows
nothing of data stores for example.  Application portability is the
main thing we should be interested in, and strive for it.  Not just on
web servers, but on web frameworks too.

There's no way I can take any python web application, copy the files
onto any python web server and have it work.  php can do this, but we
still can not do this with python.