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
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
