Mailing-List: contact rpc-dev-help@xml.apache.org; run by ezmlm
Message-ID: <3CA13ACD.9030709@isisnetworks.net>
Date: Tue, 26 Mar 2002 22:21:49 -0500
From: Ryan Hoegg <rhoegg@isisnetworks.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
MIME-Version: 1.0
To: rpc-dev@xml.apache.org
Subject: XML-RPC and HttpClient from Jakarta Commons
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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