Sam, > Is the source for the existing 1.1 port available anywhere?
I passed the source onto David (David.Cowan at apcc.com). For my project I had to add a few features specific to our particular requirements, which rendered it incompatible with HttpClient 2.0. Unfortunately I no longer have the 'pure' port. David is now its sole keeper. > Thanks for your help. The only part of the conversion I'm actually > concerned about is the MultiThreadedHttpConnectionManager -- it's easy > enough to just ditch the rest of the missing methods/classes. Hopefully > the basic spirit behind the MultiThreaded manager can remain. I ended up ditching MultiThreadedHttpConnectionManager altogether along with NTLM & DIGEST authentication schemes and SSL support. If one needs all these goodies, she should seriously consider upgrading to Java 1.2. Choosing between simplicity & portability versus feature completeness when considering various trade-offs I opted for the former. Cheers Oleg Sam Berlin wrote: > Was there any significant overhead in using the 1.1 counterparts? > Vector and Hashtable are both synchronized which might be a > performance problem if they're used often. I don't know the internals > of HttpClient, so I can't say how often they're used. The com.sun > classes are no issue for us, as we ship with them anyway... but I > agree that a generic Java 1.1 HttpClient should probably not have the > reliance. > Thanks, > Sam > > Kalnichevski, Oleg wrote: > >> Sam, >> I thought that reliance on com.sun.* classes was a fairly bad idea. >> So I opted to replace Java 1.2 collection classes with their Java 1.1 >> counterparts. That can make maintenance of a patch against HEAD or >> 2.0 branch difficult. >> I did not add any new methods or classes but I could not resist the >> temptation of removing all of the deprecated legacy code in HttpClient. >> >> Oleg >> >> -----Original Message----- >> From: Sam Berlin [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, October 22, 2003 16:57 >> To: Commons HttpClient Project >> Cc: [EMAIL PROTECTED] >> Subject: Re: Java 1.1.8 Status >> >> >> Thanks for the reply, Oleg. >> >> Was the prior port mainly an exercise in converting >> java.util.[CollectionClasses] to >> com.sun.java.util.[CollectionClasses]? If that's the case (and >> perhaps with a few new methods sprinkled in) maintaining a patch >> against the head would probably be the best and easiest way to go. >> Although I do not quite have the time to keep the JRE 1.1 port >> completely up to date, I can help keep it relevant, if needed. >> >> Thanks, >> Sam >> >> Oleg Kalnichevski wrote: >> >> >> >>> Hi Sam, >>> >>> The fate of the JRE 1.1 port is currently not quite certain. We would >>> love the JRE 1.1 port to remain in the public domain (under Apache or >>> Apache compatible license), provided the it would be supported and kept >>> in sync with our official 2.0 branch. There is a pretty high likelihood >>> of JRE 1.1 compatibility requirement to be dropped next year as far as >>> my project is concerned (the one that pays my bills, I mean). None of >>> HttpClient regulars seems to have any bandwidth left for the JRE 1.1 >>> port either. >>> I passed the JRE 1.1 port onto David Cowan (David.Cowan at apcc.com) >>> who >>> expressed his willingness to help maintain the port. But we still have >>> to decide on the details of how exactly the port is supposed be >>> managed. >>> I suggest that we invite David to join the discussion. There are a few >>> options to consider, ranging from starting a separate SourceSafe >>> project >>> to maintaining a patch against the official 2.0 branch. I am personally >>> fine with any approach as long as our (rather scarce) resources do not >>> end up spread too thin. We already have two branches to maintain >>> (2.0-stable & 2.1-development) with 3.0 branch coming some time next >>> year. All I want to see is that new people would step in to maintain >>> the >>> JRE 1.1 port. >>> >>> Cheers >>> >>> Oleg >>> >>> >>> >>> >>> >>> We would love to make the JRE 1.1 available for . >>> >>> >>> >>> On Tue, 2003-10-21 at 22:23, Sam Berlin wrote: >>> >>> >>> >>> >>>> Hello everyone, >>>> >>>> Before inquiring as to the Java 1.1.8 status, let me introduce >>>> myself. My name is Sam Berlin, and I'm a developer for LimeWire >>>> (www.limewire.org). We are in the process of adding more generic >>>> HTTP handling to LimeWire, and have run into one of the many >>>> problems with Sun's HttpUrlConnection -- mainly, the fact that it >>>> hangs if a socket is closed before any input is read. It is >>>> possible to wrap all HttpUrlConnection openings around another >>>> class and have some watchdog thread kill them off as they hang, but >>>> ideally we wouldn't have to do that. The quandry brought us to >>>> looking at other http managers, and ultimately Jakarta's HttpClient. >>>> >>>> I have succesfully (and very easily!) managed to convert some >>>> places in our code to using HttpClient, but we must allow backwards >>>> compability with Java 1.1.8, as we have many MacOS 9 (and below) >>>> users. (We still receive 10,000+ downloads a week from Mac Classic >>>> users.) We would very much like to use HttpClient, as it seems to >>>> have a very generic/extensible structure that would fit very well >>>> into other places of our code. >>>> >>>> Searching the archives revealed that Oleg Kalnichevski posted on >>>> Sept 23rd that he ported rc1 to be compatable with 1.1.8. Will >>>> this process be continuing? Is there a 1.1.8 compatable version >>>> (or is one planned) for rc2 and the eventual release? >>>> >>>> Thank you in advance, and my apologies for immediately asking a >>>> question after joining the list. >>>> Sam >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: >>>> [EMAIL PROTECTED] >>>> For additional commands, e-mail: >>>> [EMAIL PROTECTED] >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: >>> [EMAIL PROTECTED] >>> For additional commands, e-mail: >>> [EMAIL PROTECTED] >>> >>> >>> . >>> >>> >>> >>> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> >> >> . >> >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > . > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
