On Wed, Sep 23, 2009 at 1:03 PM, Aaron Watters <arw1...@yahoo.com> wrote: > > > --- On Wed, 9/23/09, Graham Dumpleton <graham.dumple...@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. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com