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 <[EMAIL PROTECTED]> 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
