You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Hans Bergsten <ha...@gefionsoftware.com> on 2000/01/12 05:51:49 UTC

Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container

"Anil K. Vijendran" wrote:
> [...]
> Let me summarize and see if we can actually nail this sucker and not
> revisit it again.
> 
> There's the following issues I can see here.
> 
> 1. Creating and actively working in parallel on two different code bases.
>    Should we do it or not?

My vote would be yes. We need to take care of the short term things, listed in 
the 3.1 plan, within a reasonable time frame. The best way to do this is to use the 
current code base. But that doesn't mean we can't start looking at the future in 
parallel (see more below).

> 2. Tomcat.Current vs Tomcat.Next. Do we believe that having a release in
>    March is not so important as having a clean codebase and team together?

This is not an either or in my mind. The things listed in the 3.1 plan are
pretty minor adjustments. Do them based on the current code base.
  
I'm thinking about what we do after the next release. Things discussed for the 
future requires a lot more work; things like load balancing, support for 
different configurations (stand-alone, embedded, add-on, etc.), configurable 
session persistence, administration functions (e.g. being able to start/stop 
contexts individually), etc.
  
Tomcat.current was not designed with these goals in mind. What will it take
to make it feasible for someone outside the original design team to help out 
with the development of these major features? How much must the architecture
be changed? We need documentation, cleaned up and commented code to answer
these questions. No one seems to have the time to do this now, so it looks
like after the release of 3.1, we'll have to wait for someone to document the
current architecture, analyze what must be done, and then we can start adding
the big stuff. How long will that take?

If we instead start with Tomat.next now, with an architecture based on the
current requirements, we will have a great understanding of what kind of
architecture it takes to fulfill the goals. This can help us compare the
efforts of continuing development based on Tomcat.next or Tomcat.current.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com