jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ossf...@dubioso.net>
Subject Re: The state of WebDAV Clients
Date Thu, 29 Nov 2007 16:17:14 GMT
Mike Oliver wrote:

> The Slide WebDAV client is quite mature, so the effort to move it and
> repackage it will be relatively small and I will pitch in.

I thought Angela wanted to see the refactoring of the Jackrabbit
WebDAV codebase happening in the Jackrabbit community. I'm not sure
that Jackrabbit is the place to start a new WebDAV effort based on
the Slide code. A new lab maybe? http://labs.apache.org/

>From a support point of view, it makes sense to start with the
Slide codebase which is known to be used in the wild. It could
be provided for the existing users for some time. (Except that it
will be hard if not impossible to cut a release without having
an offical project.)
But Jackrabbit will not be able to switch to that codebase easily.
If the goal is to avoid redundant efforts by having a single
WebDAV client library, it will be inevitable to merge the additional
Jackrabbit functionality, or provide plug-in points. That will be
much easier starting from the Jackrabbit codebase.
What is your plan? Switch over from the Slide to the Jackrabbit
codebase when the change from HttpClient 3.1 to 4.0 is due? That
will break any code related to the HttpClient, so it would be a
good occasion to break the rest of the API as well. But it also
means to basically start again from where we are now.

A WebDAV client needs a representation for the WebDAV-specific
data in the messages. That is the part of the API that is not
(or only to a minor degree) affected by changing the underlying
HttpClient API. The Jackrabbit and Slide WebDAV codebases use
different APIs for that purpose. Just as an example, the two
"properties" packages:


Since Jackrabbit is the only remaining WebDAV-related project
at Apache that I am aware of, a separate WebDAV project will
have to treat them as the primary target user. From that point
of view, it would make sense to start with the Jackrabbit
Or else we could assume that the API of the new client will
become completely different from both anyway, so that it
doesn't matter where to start.

I'm sorry if I sound gloomy, but I'd really like to know the
plan/strategy/vision/buzzwordofyourchoice for the infant project
before somebody dives into the code.

By the way, is it time to take this discussion to a dev@ list?


View raw message