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]
