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]
