Dirk Verbeeck wrote:
>Rodney Waldhoff wrote:
> > It may make sense to someday (maybe someday > soon) move the WebDAV
>methods into HTTP > client, maybe as an add-on or optional > package/JAR.
> > > This might actually make it easier to help keep Slide > in sync with
>HTTP Client--if we can clearly distinguish > the public interface (i.e.,
>the methods used by Slide) > from the private one (i.e., the way in which
>the > HttpMethod implementations make use of HttpMethodBase), > we could
>change the "back-end" and not the front and > Slide wouldn't be
>inconvienced at all.
> > > The WebDAV methods would also provide additional > examples of
>HttpMethod implementations, and may > be useful outside of Slide anyway
>(perhaps a client
> > that needs to interface with a WebDAV server?)
> > > Anyone from the Slide team care to weigh in?
>Actually, the Slide Client does very well with other WebDAV servers.
I think you misunderstood me. I'm not at all suggesting that the Slide
client doesn't interoperate with other WebDAV servers, but rather that the
WebDAV implemenations of HttpMethod currently in Slide may be useful to
non-Slide WebDAV clients. Ian for example seems to have some need for
certain WebDAV implemenations of HttpMethod, but not for the full Slide
client.
>Moving the WebDAV client code to common makes it easier to keep in sync
>with HttpClient but makes it harder to keep in sync with the WebDAV server
>code.
I'm assuming (perhaps incorrectly) that it is possible to isolate the
methods used by Slide and clients of Slide from those that are used by/with
HttpClient, and that the former don't need to change very often. (In fact, I
would think most of those "public" methods are already factored out into the
HttpMethod interface, leaving only a few method-specific public methods to
worry about.)
Once we get to a stable release, the latter shouldn't need to change very
often either, so I suppose the maintenance argument is kind of a wash.
>The some WebDAV specs are still in draft and are changing...
That one is certainly tricker. Frequent releases might be one way to address
it.
More generally, it seems reasonable to me to expect, even to seek out new,
non-core methods to roll into the HttpClient code base. If the intention
isn't to support and even provide methods from outside of the HTTP
specification, then we've made a design error in making HttpMethod the
primary abstraction. But I don't feel any particular sense of urgency on
that point.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
