On Wed, 22 Aug 2001, Dirk Verbeeck wrote:
> 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
Last I checked, slide is an application (cms), whereas http and webdav are
infrastructural (protocols). So there really is a big difference.
> 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
I won't speak for Rodney but I wasn't following slide. I've done content
management stuff for years, I recognize what it's trying to accomplish and
even respect the design aspects that I disagree with but I need http and
dav client support, not all of the higher level services that slide
provides.
> 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...
No, what's confusing is maintaining infrastructural bits with application
bits. An application that manages content and metadata should not be
bound by the protocol layers that support it and vice versa; ergo, they
should be maintained independently. I could see why you'd separate
the http and dav clients, making a distinction between standard http and
http extensions seems arguably reasonable. Putting httpclient and
webdavclient in commons makes a good deal of sense: they'd be decoupled
from the application and therefore more likely to be exercised and
developed independently. Let protocols be protocols and applications be
applications.
cheers,
-Ian
--
Ian Kallen <[EMAIL PROTECTED]> | AIM: iankallen
