hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Dever <jsde...@sympatico.ca>
Subject Re: What about optional components?
Date Thu, 20 Feb 2003 16:39:19 GMT
Thats a fine idea.  I'm all for it.
+1

Oleg Kalnichevski wrote:

>Jandalf
>
>I see your point. However, there's a concern which I would like to be
>taken into consideration. It might take quite a while before we make it
>past 2.2 release. A lot of useful code may simply be lost during that
>time. There has already been a few cases when the contribution did not
>merit inclusion into the main HttpClient source tree but might still be
>considered useful for some users. 
>
>I was thinking about something very simple for a start: just another
>folder under <root>/src folder. Something like <root>/src/contrib, which
>would contain a package named org.apache.commons.httpclient.contrib or
>something similar. This package would not be officially maintained. It
>would not be included into neither BIN nor SRC distribution, however, it
>would still be available for retrieval from CVS. In this way we might
>benefit from receiving feedback on what kind of optional features are
>considered popular or useful by the HttpClient's user base 
>
>In my opinion, this approach would not unnecessarily broaden the scope
>of the project, but might still help in fostering a greater ecology
>around HttpClient
>
>Cheers
>
>Oleg
>
>
>
>On Wed, 2003-02-19 at 18:02, Jeffrey Dever wrote:
>  
>
>>Interesting.  It sounds like we are talking about a 2.2 (or 3.0 feature) 
>>but it is possible.  One conern I have is that HttpClient is a very 
>>large project as part of commons, and if we do increase its scope then 
>>we may also be considering moving to be a top level Jakarta project.
>>
>>I would not suggest this now, but perhaps this might be in store for 3.0.
>>
>>Jandlaf.
>>
>>
>>Michael Becke wrote:
>>
>>    
>>
>>>Sounds like a fine idea Oleg.
>>>
>>>I agree we should probably look to other jakarta project for how they 
>>>handle this kind of thing.  As you said Ant does this and I believe 
>>>Log4j does as well.
>>>
>>>Mike
>>>
>>>Oleg Kalnichevski wrote:
>>>
>>>      
>>>
>>>>Adrian (and all)
>>>>
>>>>I agree that with you about keeping HttpClient JVM independent and
>>>>reasonably generic. Clearly proxy detection should be kept outside
>>>>HttpClient package IMHO.
>>>> 
>>>>But you know what? Maybe HttpClient have matured well enough so that we
>>>>have reached the point where we should start (thinking about) collecting
>>>>contributions or optional packages (pretty much in the same manner Ant
>>>>is structured into core & optional packages) that are not officially an
>>>>integral part of HttpClient, nevertheless useful enough to be made
>>>>available to the public? Would it be worthwhile having a greater ecology
>>>>around HttpClient? Any thoughts?
>>>>
>>>>Cheers
>>>>
>>>>Oleg
>>>>
>>>>On Wed, 2003-02-19 at 13:23, Adrian Sutton wrote:
>>>>
>>>>        
>>>>
>>>>>>Could we provide the code below in some Utility function?
>>>>>>I guess this is convenient for people making Applets  - although 
>>>>>>Applets
>>>>>>are generally a bad idea :-)
>>>>>>            
>>>>>>
>>>>>Sadly, this code will not work on OS X or most non-sun JREs.  The 
>>>>>location
>>>>>of proxy information is very much platform, JVM and plugin 
>>>>>dependant.  I'd
>>>>>say it would be a bad idea to include this in HttpClient, but 
>>>>>including it
>>>>>as an initial starting point in the docs may be worth while.
>>>>>
>>>>>I guess it depends what the scope of HttpClient is, but I would have 
>>>>>thought
>>>>>that the proxy configuration should be something that's passed into
>>>>>HttpClient rather than something it tries to figure out.  A separate 
>>>>>project
>>>>>which detects proxy settings in applets on various platforms, has the
>>>>>ability to parse the auto-configuration pages for proxies etc, but 
>>>>>it really
>>>>>is a big can of worms that I don't think HttpClient needs (particularly
>>>>>coming up to a release).
>>>>>
>>>>>Adrian Sutton.
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>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