Christopher K. St. John wrote: > Ok, second round. Ok, one last time.
> 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. > > 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. > > 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. This is untrue. The old Tomcat 4 HTTP/1.1 connector is a good example of spaghetti code. It works (99% of the times, at least; Pier found the last 1%), but I defy you to explain to me how chunking is determined, how it works, and how it actually produces the chunks in one single unified buffer, using an object hierarchy three levels deep in the process. Coyote HTTP/1.1 is a lot simpler than that, because: - the HTTP/1.1 stack is written with a simple request/response API in mind, which simplifies it a lot - the servlet API interfaces implementation are isolated from it The Coyote "framework" is just a very simple API, is made of two main objects (request/response), the messaging objects and two interfaces. It seems like it is much simpler to write a connector for it rather that it is to write a connector for Catalina directly. Of course, if you try to write a really optimized connector, like the Coyote HTTP/1.1 connector, then I suppose it gets more complex. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
