----- Original Message ----- From: "Glenn Nielsen" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Saturday, June 22, 2002 7:22 AM Subject: Re: Proposal draft for Tomcat 5.0
> -1 At this time for starting work on Tomcat 5 (jakarta-tomcat-5) > How about if the proposal were amended to not set up jakarta-tomcat-5.0 until both JSRs go public-draft? This will gain you a few weeks at least. However, IMHO, we can't afford to wait on 4.1 (assuming that it hasn't gone GA by the release of the public-draft) to start on 5.0 if we want to release when 2.4 goes final. > This is not a good time to start work on Tomcat 5 based on the > proposal as put forward for the following reasons: > > 1. There are alot of new features and changes in Tomcat 4.1. > These have not been used much in production and alot of > bug fixes can be expected in that codebase over the next > 2-3 months. > > 2. Forking the codeBase will increase the amount of work it takes > to apply bug fixes, minor refactorings, etc. to the codebase. > > 3. According to the proposal all of the proposed changes are minor > except for supporting Servlet 2.4 (JSR 154) and JSP 2.0 (JSR 152). > JSR 152 isn't scheduled for public review until July 29, 2002 and > JSR 154 does not yet have a date listed for public review. > > 4. Tomcat 4.1, JTC, and Jasper 2 should have their final release > before work starts on Tomcat 5. > > The earliest I would change my vote for the Tomcat 5 proposal would be > after both JSR 152 and JSR 154 have been released for public review > and Tomcat 4.1 has had a final release. > > Regards, > > Glenn > > Remy Maucherat wrote: > > > > Bill Barker wrote: > > > Firstly, let me add my +1 to the proposal. tomcat-dev could use more > > > warm-and-fuzzies. ;-) > > > > Thanks :) > > > > >>I have been following the discussion regarding the Tomcat 5 proposal. > > >> > > >>I have some general comments. > > >> > > >>Improve Performance Goal: > > >> > > >>I agree with Chritopher that in order to make improved performance > > >>a goal you need to have metrics by which you can measure whether you > > >>have met that goal, not anecdotal evidence. Catalina consists of > > >>a number of different components; mod_jk, http, JSP, SSI, CGI, etc. > > >>Some of these components can have different performance characteristics > > >>based on how they are being used. For example a simple HelloWorld.jsp > > >>versus Complex500Tags.jsp. This begs for a performance testing suite > > >>which can provide consistent reproducable results. If there is enough > > >>interest in this perhaps a separate repository could be created called > > >>jakarta-tomcat-bench. The benchmarks could be used to measure performance > > >>of different tomcat versions and other containers as well. > > > > > > > > > +0 > > > I'd probably use it if somebody else did the work, but I agree with Remy > > > that any single benchmark suite isn't going to tell you how your particular > > > web-app will perform. > > > > +1. > > > > It is not Tomcat buisness to define benchmarks or a workload. Others > > spent years doing that. If you're interested to do it, maybe you can > > start a project in commons, but this is off-topic here. > > > > Or, you can pick up your favorite load, run it once in a while, and post > > the results for us to enjoy. > > > > >>Proposal in General: > > >> > > >>The proposal is pretty vague on details. I have seen a number of > > >>replies stating "That's an implementation detail". I for one would > > >>like to see the proposal broken out into much more detail before > > >>work starts. Perhaps we should take a step back and start asking > > >>questions first so that there is more information and consensus for > > >>a formal proposal. Questions like: > > >> > > >> 1. What code in Tomcat really smells bad? > > > > > > > > > This is an evolution. Anything that smells bad can be fixed in 4.1.x (and > > > will be picked up by 5.0.x). If you want a revolution, that is another > > > proposal. > > > > *NO* code will be removed, except o.a.c.connector.*, which is indeed a > > bad implementation. That particular item is explicitely stated in the > > proposal. > > > > Other than that, other small refactorings will probably happen in both > > 4.1 and 5.0, but they are small refactorings which we will consider on a > > case by case basis. > > > > I am strongly in favor of maintaining compatibility (source and binary) > > with the 4.1 modules. We've lost a lot of time rewriting them, and I > > don't want to do that again. > > > > >>My fear is that work on Tomcat 5 will turn into a CVS version of > > >>the wild wild west if the proposal isn't detailed enough. > > > > > > > > > Again, this is an evolution. Currently in 4.1.x the only supported > > > connectors (with the exception of Warp, which Remy wants to bring in) use > > > Coyote. The proposal is little more than to expose a little bit more of > > > Coyote to the servlet-container to allow for some additional optimizations. > > > In addition, it removes the (currently deprecated) o.a.c.connectors.**, and > > > o.a.ajp.**. Think of it as spring cleaning. > > > > +1. Good summary. > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
