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

[Ian Bicking]

2009/9/23 René Dudfield <renesd at gmail.com>

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


As mentioned, all the major libraries work in unicode.


> tainting,


Tainting isn't how Python has approached security problems.  We've used
proper quoting and now in templating there is largely consensus around
treating everything as suspect except what is explicitly marked as okay
(which is essentially what DB abstractions do as well).


> http proxies,


Well, kind of off topic, but paste.httpserver has two keys:
paste.httpserver.proxy.scheme and paste.httpserver.proxy.host.  If we could
standardize those that would be nice, and we could have http proxies.  Not
the most efficient proxies (this is a good domain for async), but they'd
work.

If you mean backend proxying, then yes, there is a general lack of consensus
over how to do it (bigger than just in Python).  Since we have a reasonably
functional and knowledgable group of people here it might be a good place to
discuss and document these issues.


> http clients,


WSGIProxy has an HTTP client interface for WSGI.


> user supplied buffers,


Not clear on the issue here.


> async,


Yes; if people take this up separately so that it can be implemented on its
own timeline, that would be very good.  Given all the divergent async work
lately the time is ripe.


> latest http RFCs,


Is there a problem here?  (Well, there is an outstanding issue for 1.1 or 2,
to specify how chunked requests and responses should work.)


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

All the major frameworks use WSGI.  I don't see how layers indicate any
problem.

I don't know if you are actually intending to critique WSGI or not, but I
think we've been doing a pretty good job.

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.
>
>
Configuration and application setup are indeed outside the scope of WSGI.
I've tried to create something general with Paste Deploy that would largely
address this, but it hasn't seen a lot of interest outside a couple
frameworks (Pylons, TG via Pylons, Repoze).  It would be awesome if we could
look at this problem -- I don't care if Paste Deploy is the implementation,
but I think the scope of work it tackles is important.  People are
definitely thinking about these general ideas with respect to Django, as the
issue of the settings module seems to be on several people's minds --
unfortunately the issue of configuration is abstract enough and confusing
enough that people frequently won't *see* that they are thinking about the
same thing.  So just framing the question well is an important and difficult
task.



-- 
Ian Bicking  |  http://blog.ianbicking.org  |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20090923/f60cfedb/attachment-0001.htm>