"Ian Kallen " wrote:
> Yes, my point is that slide.jar and webdavlib.jar actually contain a lot
> of functionality in similar respects to httpclient; useful outside of the
> context of slide (i.e. mod_dav). But since they're not part of commons
> it's yet-another-tree-to-follow-to-leverage-a-few-cool-libraries. It's my
> opinion that that code will be better maintained and exercised as part of
> commons than hidden away amongst all of the slide stuff.
>
> And, I don't presently care about the search, acl and versioning specs
> that are eventually going to mature on the webdav cutting edge. When
> they're ready and there are reference implementations, great, but I'm not
> going to require those groovy features when what I want is MKCOL, MOVE and
> COPY :)
I don't see the difference between using a CopyMethod in the slide.webdav package
and using a CopyMethod in a commons.webdav package.
The Slide client WebDav support is really a separate library...
If you don't like the wrapper class don't use it ( I myself also only use the
HttpClient and *Method classes).
If your point is that you want one distribution why not use the Slide
distribution? It has everything you want: a HttpClient, httpMethods and the
webdav Methods. Nicely packaged, versioned and tested. If you don't want the
examples and test program, ... just try to ignore them...
You could move the client webdav code to commons, but the same applies to the
slide engine, it's also a component that is being used without the webdav server
protocol component and the webdav server protocol component could also move to
commons. I could use it to build and intelligent webdav proxy/router that analyses
the requests.
The only thing you would get is versioning problems.
I don't know the reason why the http methods were separated from the webdav
methods but I'm sure it was for a reason... I'm find it strange that now (2-3
months later), you and Rodney say: lets integrate them into one project... That's
what we had a couple of months ago. A full client with httpmethods and webdav
methods in one distribution. (webdavlib.jar included then the http methods as
well).
Maybe moving HttpClient to commons was a mistake and we should have kept
everything in one place.
Having 2 distributions seems confusing...
Dirk
