You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Jason Harrop <jh...@gmail.com> on 2008/01/14 01:01:30 UTC
Re: The state of WebDAV Clients
Did this conversation end up moving? If not, I'm a little unclear on
its conclusions.
The two questions seem to be:
- what codebase to start with
- where to put it
Given that the existing Slide WebDAV client is used in the wild and
works, wouldn't the starting point be to put that somewhere where work
on and with it can continue?
IMHO, having it somewhere other than in Jackrabbit (eg hc.apache.org)
would be good, since that sends a clear signal that the code is intended
to be a generic client, which in turn ought to attract a wider pool of
developers and users.
thanks
Jason
Roland Weber wrote:
> By the way, is it time to take this discussion to a dev@ list?
Re: The state of WebDAV Clients
Posted by Jason Harrop <jh...@gmail.com>.
Jason Harrop wrote:
> Ultimately, I decided to create a new project out of the Slide WebDAV
> client library, at https://sourceforge.net/projects/webdavclient4j/
>
:
>
> I'm not sure yet of the priority of migrating it to a newer version of
> HttpClient - that will become clearer over time.
>
webdavclient4j now uses commons-httpclient 3.0.1.
webdavclient4j also works with VFS WebDAV, provided you apply
http://issues.apache.org/jira/browse/VFS-74
Re: The state of WebDAV Clients
Posted by Jason Harrop <jh...@gmail.com>.
Hi Roland
Thank you for your considered and insightful advice.
Ultimately, I decided to create a new project out of the Slide WebDAV
client library, at https://sourceforge.net/projects/webdavclient4j/
This seems to me to meet several objectives:
- be able to commit changes to the code
- provide a webdavclient which is seen to be independent from any
particular WebDAV server implementation (and ultimately may work with
several)
I'm not sure yet of the priority of migrating it to a newer version of
HttpClient - that will become clearer over time.
kind regards
Jason
Roland Weber wrote:
> Hello Jason,
>
> Jason Harrop wrote:
>>
>> My interest is in WebDAV enabling the filechooser in docx4all.
>>
>> VFS has support for WebDAV. See
>> http://svn.apache.org/viewvc/commons/proper/vfs/trunk/sandbox/src/main/java/org/apache/commons/vfs/provider/webdav/
>>
>>
>> There is a file chooser: http://vfsjfilechooser.sourceforge.net/
>> and also an SWT implementation: http://commons-vfs-ui.sourceforge.net/
>>
>> VFS's WebdavFileObject imports org.apache.webdav, which is the Slide
>> client library.
>>
>> So I'm still interested in the Slide client library, and
>> I would like it to remain alive, even though it probably won't
>> need to change much (if at all) until migration to HttpClient 4.0.
>
> The Slide client library cannot "remain" alive, because it is
> already dead. The definition of a project that is alive at
> Apache is that there is a community that supports users.
> Slide lost that community long ago. Without anyone working
> actively on the codebase, no new community will gather.
> Being alive and not needing much change is mutually exclusive
> for the Slide client, IMHO.
>
> If you don't need changes, you can get the last released
> version from the archives, or you can pull the source from
> the trunk and compile yourself. If you need minor changes,
> you can modify the source after pulling it from trunk, and
> you can create bug reports and attach your patches there
> for others.
>
>> Roland Weber wrote:
>>> The slide-dev list is still open.
>>> Bugzilla for Slide is still open. While it would certainly raise
>>> some eyebrows if anyone started working on the trunk of a
>>> retired project, I don't see why it should not be possible to
>>> create a sandbox for the WebDAV client in the Slide repository.
>>> As long as somebody's working there, we wouldn't lock the repository.
>>> Jackrabbit probably wouldn't mind to get the Slide discussions
>>> off their users list either ;-) Sooner or later, the activity
>>> ceases or the project is taken to the Incubator. Then it is time
>>> to lock the Slide repository.
>>
>>> It would take a leader who is a Jakarta committer to create the
>>> sandbox, move the initial code, and apply patches if any are sent.
>>
>> I am not a Jakarta committer. Any idea how we might find a sympathetic
>> one?
>
> Jakarta committers still interested in Slide are probably
> still subscribed to the slide-dev@jakarta mailing list.
> Jakarta committers with a general cross-Jakarta interest
> are supposed to be subscribed to general@jakarta.
>
>> Alternatively, what about the vfs sandbox?
>
> Why should Commons be interested in moving unsupported code without
> a developer community from the Jakarta to the Commons repository?
>
>
> For what it's worth, here's my view on your problem:
> You want to use WebDAV support in VFS. The VFS WebDAV module is
> in a sandbox and has no perspective of ever being promoted, since
> it relies on the Slide WebDAV client which is retired for lack of
> a community, and which in turn relies on HttpClient 2.0 which has
> been unsupported for years because it is replaced by HttpClient 3.0
> and more recently HC 3.1. You are riding a dead horse. Dismount.
> Moving the corpse into a different stable won't help.
> http://www.thehumorarchives.com/joke/Beating_a_Dead_Horse
>
> If you're interested in WebDAV support for VFS, you should instead
> be looking for volunteers that port the current Slide-based module
> from Slide over to the Jackrabbit WebDAV client. The latter is based
> on the current HttpClient 3.1 version, which will remain supported
> for a few years. The effort is still worthwile, if you can find
> interested developers. Places to look for those are the Commons and
> Jackrabbit (dev) lists.
>
> cheers,
> Roland
>
>
>
>
>
Re: The state of WebDAV Clients
Posted by Roland Weber <os...@dubioso.net>.
Hello Jason,
Jason Harrop wrote:
>
> My interest is in WebDAV enabling the filechooser in docx4all.
>
> VFS has support for WebDAV. See http://svn.apache.org/viewvc/commons/proper/vfs/trunk/sandbox/src/main/java/org/apache/commons/vfs/provider/webdav/
>
> There is a file chooser: http://vfsjfilechooser.sourceforge.net/
> and also an SWT implementation: http://commons-vfs-ui.sourceforge.net/
>
> VFS's WebdavFileObject imports org.apache.webdav, which is the Slide client library.
>
> So I'm still interested in the Slide client library, and
> I would like it to remain alive, even though it probably won't
> need to change much (if at all) until migration to HttpClient 4.0.
The Slide client library cannot "remain" alive, because it is
already dead. The definition of a project that is alive at
Apache is that there is a community that supports users.
Slide lost that community long ago. Without anyone working
actively on the codebase, no new community will gather.
Being alive and not needing much change is mutually exclusive
for the Slide client, IMHO.
If you don't need changes, you can get the last released
version from the archives, or you can pull the source from
the trunk and compile yourself. If you need minor changes,
you can modify the source after pulling it from trunk, and
you can create bug reports and attach your patches there
for others.
> Roland Weber wrote:
>> The slide-dev list is still open.
>> Bugzilla for Slide is still open. While it would certainly raise
>> some eyebrows if anyone started working on the trunk of a
>> retired project, I don't see why it should not be possible to
>> create a sandbox for the WebDAV client in the Slide repository.
>> As long as somebody's working there, we wouldn't lock the repository.
>> Jackrabbit probably wouldn't mind to get the Slide discussions
>> off their users list either ;-) Sooner or later, the activity
>> ceases or the project is taken to the Incubator. Then it is time
>> to lock the Slide repository.
>
>> It would take a leader who is a Jakarta committer to create the
>> sandbox, move the initial code, and apply patches if any are sent.
>
> I am not a Jakarta committer. Any idea how we might find a sympathetic one?
Jakarta committers still interested in Slide are probably
still subscribed to the slide-dev@jakarta mailing list.
Jakarta committers with a general cross-Jakarta interest
are supposed to be subscribed to general@jakarta.
> Alternatively, what about the vfs sandbox?
Why should Commons be interested in moving unsupported code without
a developer community from the Jakarta to the Commons repository?
For what it's worth, here's my view on your problem:
You want to use WebDAV support in VFS. The VFS WebDAV module is
in a sandbox and has no perspective of ever being promoted, since
it relies on the Slide WebDAV client which is retired for lack of
a community, and which in turn relies on HttpClient 2.0 which has
been unsupported for years because it is replaced by HttpClient 3.0
and more recently HC 3.1. You are riding a dead horse. Dismount.
Moving the corpse into a different stable won't help.
http://www.thehumorarchives.com/joke/Beating_a_Dead_Horse
If you're interested in WebDAV support for VFS, you should instead
be looking for volunteers that port the current Slide-based module
from Slide over to the Jackrabbit WebDAV client. The latter is based
on the current HttpClient 3.1 version, which will remain supported
for a few years. The effort is still worthwile, if you can find
interested developers. Places to look for those are the Commons and
Jackrabbit (dev) lists.
cheers,
Roland
Re: The state of WebDAV Clients
Posted by Jason Harrop <jh...@gmail.com>.
Hi Roland
Thanks for your response.
Roland Weber wrote:
> The Slide codebase currently resides in the Slide repository at
> Jakarta. Every Jakarta committer has access to that repository.
> The repository is still open.
My interest is in WebDAV enabling the filechooser in docx4all.
VFS has support for WebDAV. See
http://svn.apache.org/viewvc/commons/proper/vfs/trunk/sandbox/src/main/java/org/apache/commons/vfs/provider/webdav/
There is a file chooser: http://vfsjfilechooser.sourceforge.net/
and also an SWT implementation: http://commons-vfs-ui.sourceforge.net/
VFS's WebdavFileObject imports org.apache.webdav, which is the Slide
client library.
So I'm still interested in the Slide client library, and I would like it
to remain alive, even though it probably won't need to change much (if
at all) until migration to HttpClient 4.0.
Roland Weber wrote:
> The slide-dev list is still open.
> Bugzilla for Slide is still open. While it would certainly raise
> some eyebrows if anyone started working on the trunk of a
> retired project, I don't see why it should not be possible to
> create a sandbox for the WebDAV client in the Slide repository.
> As long as somebody's working there, we wouldn't lock the repository.
> Jackrabbit probably wouldn't mind to get the Slide discussions
> off their users list either ;-) Sooner or later, the activity
> ceases or the project is taken to the Incubator. Then it is time
> to lock the Slide repository.
> It would take a leader who is a Jakarta committer to create the
> sandbox, move the initial code, and apply patches if any are sent.
I am not a Jakarta committer. Any idea how we might find a sympathetic
one? Alternatively, what about the vfs sandbox?
kind regards
Jason
Re: The state of WebDAV Clients
Posted by Roland Weber <os...@dubioso.net>.
Hello Jason,
Jason Harrop wrote:
> Did this conversation end up moving?
> If not, I'm a little unclear on its conclusions.
My personal summary is in the latest Jakarta board report. [1]
> The two questions seem to be:
>
> - what codebase to start with
>
> - where to put it
>
> Given that the existing Slide WebDAV client is used in the wild and works,
> wouldn't the starting point be to put that somewhere where work on and with
> it can continue?
I won't comment on that. There are valid points for both codebases.
My interest starts with the migration to HttpClient 4, which will
break either API.
> IMHO, having it somewhere other than in Jackrabbit (eg hc.apache.org) would
> be good, since that sends a clear signal that the code is intended to be a
> generic client, which in turn ought to attract a wider pool of developers
> and users.
Only HttpComponents committers have access to the hc repository.
None of us can spare the cycles on that, nor are we interested
in having code without a community that wasn't even developed
by our project.
If the Slide codebase is used to get going, there is no point in
bringing it into Jackrabbit. Only Jackrabbit committers have access
to the Jackrabbit repository. And the Jackrabbit project probably
has little interest in bringing in code without a community that
they don't need for Jackrabbit.
Every Apache committer can request a Lab [2]. Labs are meant for
one-person activities, although it probably will be possible that
other (current!) Apache committers get access to an existing
codebase. It would take a leader to request the new lab, move
the initial code, and apply patches if any are sent.
The Slide codebase currently resides in the Slide repository at
Jakarta. Every Jakarta committer has access to that repository.
The repository is still open. The slide-dev list is still open.
Bugzilla for Slide is still open. While it would certainly raise
some eyebrows if anyone started working on the trunk of a
retired project, I don't see why it should not be possible to
create a sandbox for the WebDAV client in the Slide repository.
As long as somebody's working there, we wouldn't lock the repository.
Jackrabbit probably wouldn't mind to get the Slide discussions
off their users list either ;-) Sooner or later, the activity
ceases or the project is taken to the Incubator. Then it is time
to lock the Slide repository.
It would take a leader who is a Jakarta committer to create the
sandbox, move the initial code, and apply patches if any are sent.
As mentioned above, my interest starts with the migration to the
HttpClient 4.0 API after that goes beta. At that time, I will
have a look at the Apache WebDAV activities and make a decision
where to invest my spare cycles. Until then, I will keep an eye
on how things are going, and I may throw in an idea once in a
while. But I'm not going to lead or significantly support any
efforts.
cheers,
Roland
[1] http://wiki.apache.org/jakarta/JakartaBoardReport-January2008
[2] http://labs.apache.org/
RE: The state of WebDAV Clients
Posted by Mike Oliver <mo...@corenttech.com>.
I concur Jason with all points.
Ollie
-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Jason Harrop
Sent: Sunday, January 13, 2008 4:02 PM
To: users@jackrabbit.apache.org
Subject: Re: The state of WebDAV Clients
Did this conversation end up moving? If not, I'm a little unclear on
its conclusions.
The two questions seem to be:
- what codebase to start with
- where to put it
Given that the existing Slide WebDAV client is used in the wild and
works, wouldn't the starting point be to put that somewhere where work
on and with it can continue?
IMHO, having it somewhere other than in Jackrabbit (eg hc.apache.org)
would be good, since that sends a clear signal that the code is intended
to be a generic client, which in turn ought to attract a wider pool of
developers and users.
thanks
Jason
Roland Weber wrote:
> By the way, is it time to take this discussion to a dev@ list?