WebDAV in python 2.2?
GvR also wondered if Python 2.2 should support DAV ("That's another open protocol that Python could easily support out of the box.") and /F agreed, but Greg Stein, the DAV expert and champion on python-dev, remained silent.
Greg, I now know where you were. Since you're back, any comments? --Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, Aug 03, 2001 at 08:54:17AM -0400, Guido van Rossum wrote:
GvR also wondered if Python 2.2 should support DAV ("That's another open protocol that Python could easily support out of the box.") and /F agreed, but Greg Stein, the DAV expert and champion on python-dev, remained silent.
Greg, I now know where you were. Since you're back, any comments?
I saw that thread while I was deleting over 200,000 duplicate messages from my inbox :-( ... I just haven't got to that part of my "real" inbox yet. My intent was to write a short PEP because there would be a couple modules to add to the lib: 1) httpauth -- subclasses httplib.HTTPConnection to add authenticated connections. Initially using the Basic auth method, but it could also be expanded to Digest (and others) 2) davlib -- my existing module. needs a couple items of work: allow alternate/fallback XML parsers (it uses Expat + qp_xml right now), and use the authenticated HTTP connections. That is at least a start on what needs to happen. We can flesh it out with a PEP or by checking in the modules. (Moshe and I talked about httpauth a bit at the last Python Conference; I know he is interested in working on something like that) I'm not sure how we normally write tests for network-based modules, but it shouldn't be too hard to have them run against test.webdav.org. Doc should be pretty straight-forward. Cheers, -g -- Greg Stein, http://www.lyra.org/
On Fri, 3 Aug 2001 12:12:54 -0700, Greg Stein
That is at least a start on what needs to happen. We can flesh it out with a PEP or by checking in the modules. (Moshe and I talked about httpauth a bit at the last Python Conference; I know he is interested in working on something like that)
Let me just clarify what we talked about: today, the HTTPConnection already know how to respond to code 100. urllib2 has a very nifty mechanism of handling all kinds of errors. I have a feeling the responsiblity split is not correct, and I want to think about some kind of better responsibility split. I'll try and write something up soonish. -- Moshe Zadka - http://moshez.geek (if you're not cool, http://moshez.org is still working)
On Sat, Aug 04, 2001 at 10:55:44AM +0300, Moshe Zadka wrote:
On Fri, 3 Aug 2001 12:12:54 -0700, Greg Stein
wrote: That is at least a start on what needs to happen. We can flesh it out with a PEP or by checking in the modules. (Moshe and I talked about httpauth a bit at the last Python Conference; I know he is interested in working on something like that)
Let me just clarify what we talked about: today, the HTTPConnection already know how to respond to code 100.
Euh... no, it doesn't. It *should*, but it doesn't today. To do it right, a client should be able to install a callback for when the 100-Continue is sent by the server. [ in fact, httplib's HTTPConnection and HTTPResponse should one day be reworked further to support a callback style model, passing the response object; that model allows for HTTP pipelining ]
urllib2 has a very nifty mechanism of handling all kinds of errors. I have a feeling the responsiblity split is not correct, and I want to think about some kind of better responsibility split.
As I mentioned above, I'll be writing up a PEP discussing this stuff (since it is non-trivial, and I'm guessing there is more than just a couple people's input). Suggestions can go in there. I realized that it shouldn't be "httpauth" but something like "httpext" (extended stuff). We also want proxy support in there. Note that proxy support is connection-based. Authentication is per-request, but we can attach "defaults" for a connection. urllib(2) would simply use the richer HTTPConnection class, shedding some of its work. urllib is about handling a specific URL (of many varieties, not just HTTP), while the connection is about a connection to a server for multiple requests. We can bulk up the connection (IMO, via subclassing), and keep the rich facilities of urllib's "single" request basis. (yes, urllib caches and has richer error handling and stuff, but that is beside the point of beefing up the connection for *all* HTTP clients) Cheers, -g -- Greg Stein, http://www.lyra.org/
participants (3)
-
Greg Stein
-
Guido van Rossum
-
Moshe Zadka