Return-Path: <becke@u.washington.edu>
Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Delivered-To: mailing list commons-httpclient-dev@jakarta.apache.org
Received: (qmail 17046 invoked from network); 20 Feb 2003 16:47:58 -0000
Received: from mxout1.cac.washington.edu (140.142.32.134)
  by daedalus.apache.org with SMTP; 20 Feb 2003 16:47:58 -0000
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout1.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id
 h1KGm0JA002331
	for <commons-httpclient-dev@jakarta.apache.org>;
 Thu, 20 Feb 2003 08:48:00 -0800
Received: from u.washington.edu (ss1.bluebird.ibm.com [129.42.208.139])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id
 h1KGlxZH026494
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <commons-httpclient-dev@jakarta.apache.org>;
 Thu, 20 Feb 2003 08:48:00 -0800
Message-ID: <3E550694.2060702@u.washington.edu>
Date: Thu, 20 Feb 2003 11:47:16 -0500
From: Michael Becke <becke@u.washington.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Commons HttpClient Project <commons-httpclient-dev@jakarta.apache.org>
Subject: Re: What about optional components?
References: <712C530350CFD31189E500600891BEC18C79C5@tempus.leanlogistics.com>
	 <3E534DD3.50008@nose.ch>
  <000f01c2d811$bb315010$0301a8c0@cheap>	 <1045670860.4537.52.camel@kczrh-okt22.corp.bearingpoint.com>
	 <3E53B467.30706@u.washington.edu>  <3E53B8A3.604@sympatico.ca>
 <1045754355.8324.18.camel@kczrh-okt22.corp.bearingpoint.com>
In-Reply-To: <1045754355.8324.18.camel@kczrh-okt22.corp.bearingpoint.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Sounds like a good plan.  I was thinking we might want to include the 
contrib code in the source distribution.  It would be more convenient 
for users and I think it would help to promote code contribution.

Mike

+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
>