Thanks. I'm aware of the tomcat-dev list, but posted it into the user list as such a change would have a big impact on users. Should get a wider range of comments and ideas this way...
-Chris ----- Original Message ----- From: "GOMEZ Henri" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 01, 2001 11:03 AM Subject: RE: Ideas for future versions of Tomcat (a bit controversial maybe)? > Good stuff Chris. > > I forwarded to tomcat-dev, where evolutions of Tomcat > are discussed... > > - > Henri Gomez ___[_]____ > EMAIL : [EMAIL PROTECTED] (. .) > PGP KEY : 697ECEDD ...oOOo..(_)..oOOo... > PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 > > > > >-----Original Message----- > >From: chris brown [mailto:[EMAIL PROTECTED]] > >Sent: Monday, October 01, 2001 10:54 AM > >To: [EMAIL PROTECTED] > >Subject: Ideas for future versions of Tomcat (a bit controversial > >maybe)? > > > > > >Hello, > > > >I've been trying out JDK 1.4 quite a lot, and like it a lot! I was > >wondering, given that Tomcat is a "reference implementation" of the > >Servlet/JSP APIs, if it would be a good idea to become a very > >good example > >of certain new APIs as well. > > > >I've suggested a while back that the "New scalable I/O" > >channels could be > >used to boost performance. Since then, I've seen other > >opportunities for > >increasing effeciency, simplifying code, etc. For example, instead of > >maintaining and downloading APIs for logging, it might be > >better to depend > >upon the newer logging APIs. The same thing could be said of certain > >example applications (such as making Struts use the > >java.util.regex package > >instead of an external regular expression package -- but then, > >that's going > >a bit OT as there's a list for Struts too...!). Perhaps also the > >configuration could be stored using the preferences API, but I > >don't see so > >many benefits with a change of this type. > > > >Obviously, this would limit the accessibility of any such > >future version > >Tomcat to users of JDK 1.4, but I don't think that's a major > >problem in the > >majority of deployment situations (I'm guessing here, but I > >suspect it's > >quite likely to be true). Nevertheless, I think it would be a > >good step > >forward. > > > >-Chris > >
