I must be missing something, isn't Jigsaw the W3C Http SERVER implementation?
-----Original Message----- From: Gunnlaugur Thor Briem [mailto:[EMAIL PROTECTED]] Sent: Thu, May 23, 2002 9:14 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: HttpClient vs. Jigsaw vs. HTTPClient Hi HTTP client-side implementation buffs, here come the questions nobody finds all that fun, but I couldn't find them answered elsewhere, and I believe it is valuable to try to answer them (and also to publish the answers somewhere visible!) In fact I was surprised to see that a full-text search of the [EMAIL PROTECTED] archives at http://marc.theaimsgroup.com/ revealed not a single occurrence of the word "jigsaw"! I've found three open-source Java implementations of the client side of HTTP: Jakarta Commons HttpClient http://jakarta.apache.org/commons/httpclient/ Ronald Tschal�r's HTTPClient http://www.innovation.ch/java/HTTPClient/ the W3C Jigsaw HTTP client implementation http://www.w3.org/Jigsaw/ (packages org.w3c.www.http and org.w3c.www.protocol.http and subpackages) Here are my very preliminary findings: - The third has a nice extensible design (pluggable filters acting before and after connections, and caching, authentication and cookies are implemented using that framework, and also it abstracts all standard HTTP headers in classes) and comes from an authority one would assume could be trusted to write a compliant implementation :) [though the Apache community certainly gets such trust by default as well ... Ronald Tschal�r is less known, no offense, so the *default* trust is less], but after I bumped into the capital crime of a System.exit(1) in the code (and then found 17 more System.exits with a quick search) I am not thrilled about it; it may be HTTP-compliant, but it apparently doesn't comply with general Java prudence! :) But that might just indicate that a quick cleanup job is in order. - The second doesn't support HTTPS, though there are "patches" for it here and there that add such functionality. - The first and second apparently don't include any caching functionality (am I wrong here?) - The first is clearly the project most oriented towards the participation of arbitrary developers from remote corners of the Earth such as myself :) by virtue of the existing Jakarta infrastructure for open-source development. But I have no idea about relative performance, compliance, and quality levels (bug proliferation) among these implementations. Google failed me in finding any references online. Investigating this myself by testing each will be a hefty job, so I hope to lighten it by asking ... (1) has someone involved in one of these projects looked at the other two at all, for purposes of comparison in terms of compliance, performance and general level of maturity? (2) has someone NOT involved with any of these projects tried out all three and reached some kind of meaningful conclusions that would be valuable to others? I hope I'm not going to provoke any outbreaks of "my baby is cuter than yours" here, I just feel that I'm going to need to use one of these implementations (Sun's HttpURLConnection really isn't doing it for me, would you believe) and take part in its development to meet any needs of my project that aren't already met, and I want to have some basis for deciding which one it should be. Hoping for some interesting responses! If I get any that are addressed to me and not the commons-dev mailing list, then I'll send a single summary to the list. Thanks, - Gulli -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
