tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <hgo...@slib.fr>
Subject RE: [PROPOSAL/VOTE] New Repositories for Collaborative Developmen t
Date Mon, 07 May 2001 10:34:31 GMT
The title of the thread was about "Collaborative Development" :!

The objective of the new repositories are to help share some code
between all the Tomcats.

While working on using ajp12/ajp13 java code from Tomcat 3.3 CVS, 
I quickly realize the need for a common toolbox handling 
http related objects (Mimes, Cookies, MessageBytes...)

We could imagine at least three subprojects :

- jakarta-tomcat-toolbox 

  An general toolbox, which defines and handle all sorts of 
  http related projects, like cookies, mimes, request/response.
  May be code, interface, abstract (and so on)

- jakarta-tomcat-connectors

   A kind of ORB based on HTTP with both native code (to link
   with majors WebServers) and java code (interfaces to be implemented
   in tomcats). This sub-project will use the jakarta-tomcat-toolbox 

- jakarta-tomcat-jasper
 
  the JSP implementation (which could also use jakarta-tomcat-toolbox).


I can't speak for jasper34 but the connector goal is to have an 
open project with a common code for all the current 
(and future tomcats). 

I hope it will reduce questions on tomcat-user about 'mod_jk'
build, configuration and use.

In the spirit of openess, I'll send later today a document about 
the possible evolution of protocol between web-server and tomcat,
AJP14.

>We already went over this again and again and my conclusions were
>always:
> - People working on 3.3 have their own reasons to do it at the moment;
> - Work is not being lost on 4.x because the 3.3 people do not have the
>   same motivation to work on 4.x;
> - It is not a matter of one group being right and the other being
>   wrong.

Yes, There is two teams working on differents core projects. The good news
is that with the "Repositories for Collaborative Development" we could have
peoples from each group working again together. That's important.

>And that is what is happening here: at the moment (things will probably
>evolve in some different direction) there are to big groups of itches
>to scratch - 3.3 and 4.x.
>
>Instead of loosing more time fighting about the stupid concept of one
>of the groups having to be wrong, let's focus on how the two groups
>still can cooperate scratching common itches.

+1

We must locate what could be common in both branch, and shared it.

In TC 4.0, I think about the excellent works from Bip Thelin 
(TC 4.x Clustering). What make it specific to TC 4.x ? 

In contrario, why mod_jk from TC 3.3 couldn't be used in TC 4.x ?

Also shareable are all objects related to HTTP (cookies, 
messages, headers, ....).
     
Having smaller CVS, will also encourage new commiters 
contributing in area where they could be more at ease.

>There are some very interesting developments on this directions with
>mod_jk and jasper. Focusing in this kind of thing is quite productive
>and puts some of the 3.3 people cooperating in the development of the
>4.x version and vice versa.

+1

I strongly think that merging the best of 3.3 and 4.0 could make an
incredible Tomcat 5.0. Having Costin and Craig in the same team 
may be a dream but frankly what a bright combinaison.....

Let's start by sharing what could be done, it will help identify 
what's the core and what could be modules (in reference to 
Apache http server no politics here :). 
Using 4.0 Valves and 3.3 modules didn't seems incompatible. 
There is many modules in 3.3 which are not related to Request/Response...

>Trying to force one of the groups out of its way will just fragment
>this project and take the 3.3 people somewhere else (SourceForge or
>so).

Not sure it will force people to go somewhere else. Some may be just 
tired of political problem and stop contributing to ASF.
That will be bad news for both groups, and there will be no
winner in that case, the looser will be the OpenSource spirit.

>In due time, the usual survival rules will tend to favor the
>solution that proves to be the best and everybody will work together
>again... until the next revolution.

A sort of 'Software Darwinism' and species adaptability.


Mime
View raw message