XML-RPC and HttpClient from Jakarta Commons

[Ryan Hoegg <rh...@isisnetworks.net>]

Hello all,

Quick link to HttpClient: http://jakarta.apache.org/commons/httpclient/

After a bit more research into the Apache projects I think I may want to 
revisit the inclusion of the HttpClient class from the Jakarta Commons. 
 As you may have guessed I am new to the ASF projects as a whole and am 
struggling to get my head around the alliances and feuds between the 
individual projects and project groups.  I spent a considerable amount 
of time reading about Turbine, Avalon, the Commons, Cocoon, and even 
Jetspeed and Tomcat to a lesser extent.

One thing I don't understand is the relationship between this library 
(as it is now a part of the Apache XML Project) and the Jakarta Project. 
 This library is available in Java only as far as I can tell, so why be 
a part of one and not the other?  If the developers of the library (you) 
had decided against Jakarta for some reason, this would be the first 
reason not to introduce a dependency on a class from the Jakarta 
Commons.  My only objection there is that there is nothing keeping us 
from including a static version of the HttpClient class and only 
upgrading when we see fit.

In a thread early this month we began discussing the benefits of 
improving the HTTP client support within the XML-RPC library.  I think I 
am prepared to do that now:

- Because of the nature of XML-RPC, more programmers will need to use 
client functionality only than server functionality.  I found myself in 
precisely this situation when I was asked to consume an ASP's XML-RPC 
service in order to complete a task for a customer.

- Some XML-RPC services in production use today require extended HTTP 
capabilities such as cookies, custom headers, and HTTP 1.1 features such 
as chunking and compression.  In addition, some use SSL.  This library 
currently must be modified by the user in order to support any of these 
features.

My recommendation is to change the code of XmlRpcClient, and 
XmlRpcClientLite to use HttpClient from the Commons to communicate with 
XML-RPC servers.  This is because it includes support for all of the 
features mentioned.  One feature that has already been added to this 
library would have been provided by this change: the use of HTTP Basic 
Authentication.

I'd be interested in hearing the committers' thoughts on this, and I'll 
volunteer to make a stab at the change if it is thought to be worthwhile.

Ryan Hoegg

Re: XML-RPC and HttpClient from Jakarta Commons

[Daniel Rall <dl...@finemaltcoding.com>]

Ryan, my apologies for taking so long in responding to your message.
I haven't heard from any of the other committers on this topic, but I
am very much in favor of your proposal.  My only concern is that
currently the XML-RPC JAR file is self-contained when used as a client
or in an applet.  If you can minimize the external dependency impact
and are still interested in doing some work on this project, I offer a
strong +1.

- Dan

Ryan Hoegg <rh...@isisnetworks.net> writes:

> Hello all,
>
> Quick link to HttpClient: http://jakarta.apache.org/commons/httpclient/
>
> After a bit more research into the Apache projects I think I may want
> to revisit the inclusion of the HttpClient class from the Jakarta
> Commons. As you may have guessed I am new to the ASF projects as a
> whole and am struggling to get my head around the alliances and feuds
> between the individual projects and project groups.  I spent a
> considerable amount of time reading about Turbine, Avalon, the
> Commons, Cocoon, and even Jetspeed and Tomcat to a lesser extent.
>
> One thing I don't understand is the relationship between this library
> (as it is now a part of the Apache XML Project) and the Jakarta
> Project. This library is available in Java only as far as I can tell,
> so why be a part of one and not the other?  If the developers of the
> library (you) had decided against Jakarta for some reason, this would
> be the first reason not to introduce a dependency on a class from the
> Jakarta Commons.  My only objection there is that there is nothing
> keeping us from including a static version of the HttpClient class and
> only upgrading when we see fit.
>
> In a thread early this month we began discussing the benefits of
> improving the HTTP client support within the XML-RPC library.  I think
> I am prepared to do that now:
>
> - Because of the nature of XML-RPC, more programmers will need to use
> client functionality only than server functionality.  I found myself
> in precisely this situation when I was asked to consume an ASP's
> XML-RPC service in order to complete a task for a customer.
>
> - Some XML-RPC services in production use today require extended HTTP
> capabilities such as cookies, custom headers, and HTTP 1.1 features
> such as chunking and compression.  In addition, some use SSL.  This
> library currently must be modified by the user in order to support any
> of these features.
>
> My recommendation is to change the code of XmlRpcClient, and
> XmlRpcClientLite to use HttpClient from the Commons to communicate
> with XML-RPC servers.  This is because it includes support for all of
> the features mentioned.  One feature that has already been added to
> this library would have been provided by this change: the use of HTTP
> Basic Authentication.
>
> I'd be interested in hearing the committers' thoughts on this, and
> I'll volunteer to make a stab at the change if it is thought to be
> worthwhile.
>
> Ryan Hoegg

Re: XML-RPC and HttpClient from Jakarta Commons

[Daniel Rall <dl...@finemaltcoding.com>]

Ryan, my apologies for taking so long in responding to your message.
I haven't heard from any of the other committers on this topic, but I
am very much in favor of your proposal.  My only concern is that
currently the XML-RPC JAR file is self-contained when used as a client
or in an applet.  If you can minimize the external dependency impact
and are still interested in doing some work on this project, I offer a
strong +1.

- Dan

Ryan Hoegg <rh...@isisnetworks.net> writes:

> Hello all,
>
> Quick link to HttpClient: http://jakarta.apache.org/commons/httpclient/
>
> After a bit more research into the Apache projects I think I may want
> to revisit the inclusion of the HttpClient class from the Jakarta
> Commons. As you may have guessed I am new to the ASF projects as a
> whole and am struggling to get my head around the alliances and feuds
> between the individual projects and project groups.  I spent a
> considerable amount of time reading about Turbine, Avalon, the
> Commons, Cocoon, and even Jetspeed and Tomcat to a lesser extent.
>
> One thing I don't understand is the relationship between this library
> (as it is now a part of the Apache XML Project) and the Jakarta
> Project. This library is available in Java only as far as I can tell,
> so why be a part of one and not the other?  If the developers of the
> library (you) had decided against Jakarta for some reason, this would
> be the first reason not to introduce a dependency on a class from the
> Jakarta Commons.  My only objection there is that there is nothing
> keeping us from including a static version of the HttpClient class and
> only upgrading when we see fit.
>
> In a thread early this month we began discussing the benefits of
> improving the HTTP client support within the XML-RPC library.  I think
> I am prepared to do that now:
>
> - Because of the nature of XML-RPC, more programmers will need to use
> client functionality only than server functionality.  I found myself
> in precisely this situation when I was asked to consume an ASP's
> XML-RPC service in order to complete a task for a customer.
>
> - Some XML-RPC services in production use today require extended HTTP
> capabilities such as cookies, custom headers, and HTTP 1.1 features
> such as chunking and compression.  In addition, some use SSL.  This
> library currently must be modified by the user in order to support any
> of these features.
>
> My recommendation is to change the code of XmlRpcClient, and
> XmlRpcClientLite to use HttpClient from the Commons to communicate
> with XML-RPC servers.  This is because it includes support for all of
> the features mentioned.  One feature that has already been added to
> this library would have been provided by this change: the use of HTTP
> Basic Authentication.
>
> I'd be interested in hearing the committers' thoughts on this, and
> I'll volunteer to make a stab at the change if it is thought to be
> worthwhile.
>
> Ryan Hoegg