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.
