hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Berlin <sber...@limepeer.com>
Subject Re: Java 1.1.8 Status
Date Wed, 22 Oct 2003 21:26:14 GMT
Hi again Oleg,

Is the source for the existing 1.1 port available anywhere?  I have gone 
ahead and attempted to port rc2 to Java 1.1 using the com.sun.java.util 
packages (as that's easiest, and all we really need right now), but a 
few places use brand new classes/methods.  These include NTLM (which 
uses multiple crypto methods -- the best solution is just to ditch NTLM 
authentication for Java 1.1), MultiThreadedHttpConnectionManager (using 
various java.lang.ref classes -- I'm not positive what the best solution 
here is yet), SSLProtocolSocketFactory (using 
javax.net.ssl.SSLSocketFactory -- again, the best solution is to just 
ditch SSL authentication on Java 1.1), and HttpConnection (which uses 
various get/setSendBufferSize -- perhaps the best solution is to just 
not perform the optimizations if using Java 1.1).

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.

Thanks,
 Sam

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:sberlin@limepeer.com]
>> Sent: Wednesday, October 22, 2003 16:57
>> To: Commons HttpClient Project
>> Cc: David.Cowan@apcc.com
>> 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: 
>>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: 
>>>> commons-httpclient-dev-help@jakarta.apache.org
>>>>
>>>>  
>>>>     
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: 
>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: 
>>> commons-httpclient-dev-help@jakarta.apache.org
>>>
>>>
>>> .
>>>
>>>
>>>
>>>   
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 
>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: 
>> commons-httpclient-dev-help@jakarta.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 
>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: 
>> commons-httpclient-dev-help@jakarta.apache.org
>>
>>
>> .
>>
>>  
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
>
>
> .
>



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Mime
View raw message