[Web-SIG] So what's missing?

[Ian Bicking]

On Friday, October 24, 2003, at 10:32 PM, Bill Janssen wrote:
> Client-side:

To client-side, I would add that authentication is too hard in urllib2, 
and only works for HTTP (for trivially reasons).  I think think 
urllib2's subclasses are unnecessarily complicated -- authentication 
handling could be put directly in the HTTP/HTTPS, both basic and 
digest.  Goes together with post/multipart, and I think these shouldn't 
be too hard to add.

There is also some talk about putting urllib2 and urlparse together, 
i.e., have a URL object.  The distinction between the urllib, urllib2, 
and urlparse libraries is not very good, e.g., urllib.quote (and 
friends) are more related to urlparse than urllib.  A URL object could 
unify all these.

Cookie handling also fits into this, but from the opposite direction 
from a URL object, since we are creating something of a user agent.  
You'd almost want to do:

ua = UserAgent()
url = web.URL('http://whatever.com')
content = ua.get(url)

Or something like that.  I think an explicit agent is called for, 
separate from the URLs that it may retrieve.  But only when you start 
considering cookies and caching.

If you want to take it a little further, WebDAV URLs support a bunch of 
other features.  Nice to at least keep the door open for that.

> Server-side:
>
> * Server-side SSL support in the socket module, and some interface to
>   management of certificates/identities for SSL.  I want to build
>   HTTPS servers with Python.
>
> * Some kind of response object usable in CGI scripts.  This would make
>   a few simple actions simple: write a response as a file (instead of
>   using sys.stdout), return an error with a message, redirect to
>   another URL, return a file.

I'd still really like to get a response and request object, first 
implemented for CGI but possible to target to other environments.  It's 
because I really want this that I didn't want us to get too 
experimental -- just a request and response object are very doable, and 
would be a real accomplishment.  But we can get off track with this.  
Good (standard) Python libraries aren't frameworks, they are 
straight-forward, well-documented interfaces, which is all I'm looking 
for here.

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