On Fri, 21 Jun 2002, Christopher K. St. John wrote: > People are +1'ing the _goals_ of the proposal, but I > the proposal itself doesn't give sufficient detail to > determine if the recommended actions will actually > lead to those goals being accomplished.
That's exactly the target - to set the goals and the overal direction ( it's a 'long-term plan' ). Each particular detail will be discussed and revisited many times during the implementation stage. > Some of the goals even appear to be contradictory, > but there's no discussion of the inevitable engineering > tradeoffs. Simplicity vs Flexibility is a big issue. The goal seems to be to get more flexibility and a simpler core. I seen no contradiction here - our experience so far seems to indicate that by reducing complexity you gain more flexibility. > For example, the Coyote framework is compatible with > Tomcat 3 and Tomcat 4. This is admirable, and may lead > to closer ties between the two groups of developers. > BUT Coyote is also more complicated and harder to > understand than the HTTP connector code in Tomcat 4 that > it replaces. It does more, too, but let's face it, it's > an integrated framework for writing connectors, and > frameworks are harder to understand and build than > single-purpose code. Coyote is not a framework for writing connectors - it defines the base objects and a hook mechanism. It is not perfect - and one of the goals is to improve it in tomcat5. But most of the stuff is needed to get decent performance - and to be able to support other protocols and have better integration with the server. There are many things that are hard or impossible with o.a.ajp. > That isn't to say it wasn't worth it, but you've gone > from only needing to understand o.a.c.connector to having > to understand a whole slew of packages and patterns and > conventions. There's more buy-in required. ???? What do you mean 'only o.a.c.connector' ? There are few dozens interfaces and classes you must understand, and the point is you can't get too much performance without good buffer management, byte[], optimized conversions, etc. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
