[Web-SIG] So what's missing?

[John J Lee]

On Sat, 25 Oct 2003, Ian Bicking wrote:

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

It's a minor issue, but it seems nicer to me to have authentication
separate if it can easily be separate -- that fits in with the general
philosophy of urllib2 that you pick 'n mix the features you want.  What
are the trivial reasons for it breaking on non-HTTP auth?


> Goes together with post/multipart, and I think these shouldn't
> be too hard to add.

How does this go together with post/multipart?  Do you just mean that
you're likely to post the multipart data using urllib2.urlopen?


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

It's an appealing idea, especially given the cuteness of string
subclassing ;-)


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

Are you suggesting replacing urllib2, building on top of it, or extending
it?  urllib2's handlers already gets a lot of the 'user-agent' job done.
What requirements does caching impose that urllib2 doesn't meet?  There's
already a CacheFTPHandler.


John