[Web-SIG] WSGI in standard library

[Ian Bicking]

Alan Kennedy wrote:
> [Alan Kennedy]
>  >>>Maybe we need a PEP
> 
> [Bill Janssen]
>  >>Great idea!  That's exactly what I thought when I organized this SIG a
>  >>couple of years ago.
> 
> [Guido van Rossum]
>  > At first I was going to respond "+1". But the fact that a couple of
>  > years haven't led to much suggests that it's unlikely to be fruitful;
>  > there just are too many diverging ideas on what is right. (Which makes
>  > sense since it's a huge and fast developing field.)
> 
> Having considered the area for a couple of days, I think you're right: 
> the generic concept "web", as in web-sig, covers far too much ground, 
> and there are too many schools of thought.
> 
>  > So unless someone (Alan Kennedy?) actually puts forward a PEP and gets
>  > it through a review of the major players on web-sig, I'm skeptical.
> 
> But there is a subset which I think is achievable, namely http support, 
> which IMO is the subset that most needs a rework. And now that we have a 
> nice web standard, WSGI, it would be nice to make use of it to refactor 
> the current http support. The following are important omissions in the 
> current stdlib.
> 
>   - Asynchronous http client/server support (use asyncore? twisted?)
>   - SSL support in threaded http servers
>   - Asynchronous SSL support

I lack any opinion on these.  These don't matter much to me personally.

>   - Simple client file upload support

The addition of another function like urllib.urlencode could do this, 
e.g., urllib.fileencode.  This seems fairly straight-forward.

>   - HTTP header parsing support, e.g. language codes, quality lists, etc

This would be very nice.  Clark has done some work in paste.httpheaders 
for these; but I don't think any of us (Clark included) are really 
satisfied with how that module is layed out.  Maybe it is because 
headers in general don't have that much in common with each other.  I'm 
not sure.

But nevertheless, it's all very mechanical, and based on existing and 
stable HTTP standards.  So I think it is an excellent candidate for the 
standard library.

>   - Simple object publishing framework?

That's harder.  I think path-prefix based routing would be a nice 
addition to compliment any WSGI http server, but mostly because it lives 
above the level of any particular framework.

There's small issues to any object publishing framework that make it a 
bad candidate for the standard library.

> Addressing all of the above would be significant piece of work. And 
> IMHO, it is only achievable by staying focussed on http and NOT 
> addressing requirements such as
> 
>   - Content processing, e.g. html tidy, html parsing, css parsing

Indeed; all implementations for content processing are flawed in one way 
or another, which I think implies no canonical is available, and so it's 
not a good candidate for the standard library.

>   - Foreign script language parsing or execution

Like content but even harder.

>   - Page templating API

Nothing stable and popular enough here to even consider.

> I think it would be a good idea to address these concerns in separate PEPs.

I don't think they all need PEPs.  urllib.fileencode is pretty simple, 
for instance.

> [Guido van Rossum]
>  > I certainly don't want this potential effort to keep us from adding
>  > the low-hanging fruit (wsgiref, with perhaps some tweaks as PJE can
>  > manage based on recent feedback here) to the 2.5 stdlib.
> 
> Completely agreed. Any web-related PEPs are going to take a long time, 
> and are unlikely to be ready in time for 2.5.

I don't think anything will work that requires coming up with 
implementations where there currently are none close to appropriate, or 
where we have to synthesize agreement from widely different frameworks. 
  Maybe at sometime in the future -- beyond 2.5 -- the environment will 
change; an implementation will emerge, or some new consensus on best 
practice or some new refactorings of a problem will emerge.

But lots of what we're talking about here isn't like that, so we 
shouldn't be pessimistic, just focused.

-- 
Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org