WebDAV Client, HttpClient and Commons

[Adrian Sutton <ad...@ephox.com>]

Hi all,
I'm a relative new comer around here so I apologise if this has been brought
up before, I've been lurking for some time now and I couldn't turn anything
up in the list archives so thought I'd pipe up.

Issue 1

I'm one of apparently a large number of people who are using the WebDAV
client part of slide separate from the rest of slide (it's fantastic btw).
One of the things I'd like to add is support for NTLM authentication.  This
would obviously be added to HttpClient with the benefits showing through in
the WebDAV client.  Unfortunately, Slide currently has a different version
of HttpClient than the one in commons (which we are looking at using for
other things).  So, it would be nice if we could make the nessecary changes
to Slide so that it can use the latest HttpClient from commons (and thus
benefit from all the new features being added over there).  A while back
Michael Smith noted that this update would be acceptable to the Slide
developers so I don't expect too much objection to this however I would like
to check - are there any objections to this?

Since I've only looked at the WebDAV client code I'm uncertain of how much
work is involved in this for the entirety of Slide - has anyone investigated
this?  Are we talking days, weeks or months?


Issue 2

My other suggestion is a much more controversial one so please note that I
am raising the proposal to guage the reaction rather than to change the way
things work - I will be happy to settle for whatever decision is made and
work with it as best I can.  I would like to suggest that WebDAV client be
split off into a separate commons project.  Obviously it is highly
undesirable to wind up with 2 separate branches as we currently have with
HttpClient and the issues of API compatibility should be fully discussed
before making the move.

The advantages I see for this are:
* Simpler to grab out the WebDAV client and use it independantly as many
people are starting to do.
* Larger support base for developing the WebDAV client, adding new features
etc.
* Allows better code reuse both within Jakarta and outside of it (primarily
outside of Jakarta I imagine), which is the point of commons anyway.

As I said though, I realise this is a big and controversial decision that
should rest with the Slide committers, I am suggesting this as I have a
tight schedule to keep and would like to be able to maximise the impact my
time has both for our products and for the Jakarta project and I see this as
a good way to benefit both parties.

I am keen to hear your views.

Yours sincerely,

Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: WebDAV Client, HttpClient and Commons

[Sung-Gu <je...@apache.org>]

----- Original Message -----
From: "Christopher Lenz" <cm...@gmx.de>

> Am 23.08.2002 13:28:24, schrieb "Adrian Sutton" <ad...@ephox.com>:

> >Issue 1
>
> >Michael Smith noted that this update would be acceptable to the Slide
> >developers so I don't expect too much objection to this however I would
like
> >to check - are there any objections to this?
>
> Personally I think that would be great!

Since it was seperated to develop various and strong enougbh http features,
I think, nobody has any objection surely...

Actually, the http client was donated for us to be concentrated to
only WebDAV client features.

> Of course you could start the effort before that, but it'll probably only
be
> integrated into Slide as soon as a release is out.
>
> >Since I've only looked at the WebDAV client code I'm uncertain of how
much
> >work is involved in this for the entirety of Slide - has anyone
investigated
> >this?  Are we talking days, weeks or months?
>
> I would talk days, but then I rarely talk weeks ;o)

Think so...

> >Issue 2

0.

Sung-Gu


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: WebDAV Client, HttpClient and Commons

[Christopher Lenz <cm...@gmx.de>]

Hi Adrian,

Am 23.08.2002 13:28:24, schrieb "Adrian Sutton" <ad...@ephox.com>:
>Hi all,
>I'm a relative new comer around here so I apologise if this has been brought
>up before, I've been lurking for some time now and I couldn't turn anything
>up in the list archives so thought I'd pipe up.
>
>Issue 1
>
>I'm one of apparently a large number of people who are using the WebDAV
>client part of slide separate from the rest of slide (it's fantastic btw).
>One of the things I'd like to add is support for NTLM authentication.  This
>would obviously be added to HttpClient with the benefits showing through in
>the WebDAV client.  Unfortunately, Slide currently has a different version
>of HttpClient than the one in commons (which we are looking at using for
>other things).  So, it would be nice if we could make the nessecary changes
>to Slide so that it can use the latest HttpClient from commons (and thus
>benefit from all the new features being added over there).  A while back
>Michael Smith noted that this update would be acceptable to the Slide
>developers so I don't expect too much objection to this however I would like
>to check - are there any objections to this?

Personally I think that would be great!

Back then, the code was forked because the Slide developers working on the 
webdav client were unwilling to keep up with all the API-breaking changes made 
to the commons-httpclient (which originated in Slide, as you may know). So I 
think an important requirement before going back to the commons-htppclient would 
be API stability, and thus a stable release of that component.

Of course you could start the effort before that, but it'll probably only be 
integrated into Slide as soon as a release is out.

>Since I've only looked at the WebDAV client code I'm uncertain of how much
>work is involved in this for the entirety of Slide - has anyone investigated
>this?  Are we talking days, weeks or months?

I would talk days, but then I rarely talk weeks ;o)

>Issue 2
>
>My other suggestion is a much more controversial one so please note that I
>am raising the proposal to guage the reaction rather than to change the way
>things work - I will be happy to settle for whatever decision is made and
>work with it as best I can.  I would like to suggest that WebDAV client be
>split off into a separate commons project.  Obviously it is highly
>undesirable to wind up with 2 separate branches as we currently have with
>HttpClient and the issues of API compatibility should be fully discussed
>before making the move.
>
>The advantages I see for this are:
>* Simpler to grab out the WebDAV client and use it independantly as many
>people are starting to do.
>* Larger support base for developing the WebDAV client, adding new features
>etc.
>* Allows better code reuse both within Jakarta and outside of it (primarily
>outside of Jakarta I imagine), which is the point of commons anyway.
>
>As I said though, I realise this is a big and controversial decision that
>should rest with the Slide committers, I am suggesting this as I have a
>tight schedule to keep and would like to be able to maximise the impact my
>time has both for our products and for the Jakarta project and I see this as
>a good way to benefit both parties.

My opinion, being a Slide commiter who rarely even uses the client stuff ;o), is 
that it could technically be split out, but the question is more about 
community. I.e. there would need to be enough developers committed to migrating 
the code to commons and maintaining and extending it over there. And of course 
it would help if other projects and developers showed interest in using the 
component (as you've done), otherwise it could just as well remain in Slide. 
OTOH, the Slide project has made a bad experience with submitting HttpClient to 
Commons, so I don't know what the others think about this.

--
Christopher Lenz
_______________________________________________
 /=/ cmlenz at gmx.de





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>