Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Received-SPF: pass (athena.apache.org: domain of erik@codefaktor.de designates
 62.75.252.62 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <1192956502.32214.13.camel@okhost>
References: <471A6666.2000009@dubioso.net> <1192956502.32214.13.camel@okhost>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1F8E289D-4240-45C8-B239-7AC956421EBC@codefaktor.de>
Content-Transfer-Encoding: 7bit
From: Erik Abele <erik@codefaktor.de>
Subject: Re: TLP - the final push
Date: Mon, 22 Oct 2007 14:26:16 +0200
To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>

On 21.10.2007, at 10:48, Oleg Kalnichevski wrote:

> On Sat, 2007-10-20 at 22:34 +0200, Roland Weber wrote:
>> ...
>> The first two items are obvious. Future components might
>> be a WebDAV client (from Slide), or what we used to call
>> http-spider (see Droids on labs.apache.org). I'd stretch
>> the "HTTP & related" to include Julius' nyc-ssl since
>> that is useful for https, which is related to http.
>
> +1 to all said above.

Same here, makes absolute sense, +1.

>> The application stuff is probably new in this discussion.
>> That thought started with the Slide server side, though
>> I don't expect that to be revived. Still, we should allow
>> it to reside with us in the event. To prevent that clause
>> from meaning "anything we want to do", I'd qualify it with
>> _existing_ applications (or projects). Existing in Apache
>> or outside, but no new efforts started by us directly in
>> the TLP. If we should get funny ideas for new projects,
>> we'd take them to the Incubator or the Labs or Sourceforge,
>> or we'd ask the board for approval.
>>
>> The container stuff must be stated explicitly, to leave
>> no doubt that we are not going to get into the turf of
>> Tomcat or Jetspeed or Geronimo or whatever. We're not
>> doing containers, just low-level components that they
>> or others could use to implement a container.
>>
>> Now, if we allow HTTP applications in addition to the
>> components, what's going to stop us from becoming a
>> new Jakarta... with completely separate projects on
>> their own mailing lists, which don't care about the
>> others or "the whole"? My take on this is as follows:
>> - one dev list for all
>> - one commits list for all
>> - separate user lists where appropriate
>> If people on the dev list really don't care for some
>> parts of the project, they can set up mail filter rules.
>
> +1

Again, also +1 except for the last paragraph: I wouldn't limit this  
from the start; if there's a real demand for another dev-list for  
e.g. the spider or DAV efforts then so be it - I don't see a problem  
with that as long as the focus is and stays on "HTTP" and  
"Components" then that is fine.

But let's put that aside for the time until we hit the question - you  
don't want to put some restriction like that in the TLP proposal anyway.

>> Name:
>> We do have a name, HttpComponents. I'm not concerned
>> about it's length anymore, it's just 2 characters
>> more than SpamAssassin. It will not really match with
>> applications, but that's a secondary thought. My primary
>> concern is that it is rather close to a category name.
>> An attempt to create a "security.apache.org" project
>> failed at some time in the past, the people eventually
>> chose a different name to go TLP. The "testing.apache.org"
>> idea was not too well received either in the discussion on
>> general@jakarta last year, mainly because of an unclear
>> scope and the fact that "testing" is a category.
>> So I would prefer to choose another name for the TLP.
>> I'm intentionally not suggesting anything right now,
>> I want to first establish a consensus on whether we
>> should be looking for a new name at all.
>> Mind you, I don't want to rename the HttpComponents. I
>> am talking about moving from "Jakarta HttpComponents" to
>> "Whatever HttpComponents". We've been de-emphasizing the
>> Jakarta part for several releases now, so changing that
>> should not be disruptive to users. And it should be no
>> more effort than any other domain change for us. The
>> new name would only gain a meaning of it's own when we
>> extend our activities beyond the HttpComponents.
>
> Roland,
>
> We tried to come up with a new fancy name and that led us nowhere. I
> wish we had chosen a better name from the start or were allowed to be
> http4j or some such. Good names are very difficult to come up with.
> HttpComponents may be dull and ugly but it does reflect the purpose of
> the project rather well.

While I basically agree with Roland, I'm also hesitant to start a  
whole discussion around that - personally I can't come up with a new  
name which would make sense and matches what the projects intention is.

How about the following "structure":

Apache HttpComponents HttpCore
Apache HttpComponents HttpClient
Apache HttpComponents DavCore
Apache HttpComponents DavClient
Apache HttpComponents Droids
...

I think that something like that would make the most sense (I  
splitted Slide up just as an example, it's not part of the proposal  
anyway).

>> OK, that's the brain dump... Fire away. I may not have
>> much occasion to answer next week, but don't let that
>> stop you from sharing your thoughts. I hope there will
>> be a lot more participants than just Oleg and me this
>> time around :-)
>
> I am tired of discussions that lead nowhere.

I don't think that it leads nowhere, it simply puts us on the same  
page - and since we're basically agreeing we can move on to discuss  
more specific things like the wording of the proposal :-)

Others (e.g. Ortwin and the other committers), *please* indicate if  
you're fine with that too!

> If no one else participates we should just go ahead and put a  
> proposal on vote and be done with it.

Yep, we certainly shouldn't make a big thing out of this kick-off.

Let's give it some more days so that others can chime in (*nudge,  
nudge*) and then simply take the draft [1] from the wiki and refine  
the scope/wording, make sure that we have enough participants (what's  
with the other people on the current version of the proposal?),  
decide on the chair person etc.

As soon as we have a final draft we can simply vote on it and submit it.

Cheers,
Erik

[1] http://wiki.apache.org/jakarta-httpclient/ 
ApacheHttpComponentsTlpProposalDraft


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