Mark, On 11/3/14 8:16 AM, [email protected] wrote: > Author: markt > Date: Mon Nov 3 13:16:36 2014 > New Revision: 1636347 > > URL: http://svn.apache.org/r1636347 > Log: > Put the current version of the TODO list in svn. > > Modified: > tomcat/trunk/TOMCAT-NEXT.txt > > Modified: tomcat/trunk/TOMCAT-NEXT.txt > URL: > http://svn.apache.org/viewvc/tomcat/trunk/TOMCAT-NEXT.txt?rev=1636347&r1=1636346&r2=1636347&view=diff > ============================================================================== > --- tomcat/trunk/TOMCAT-NEXT.txt (original) > +++ tomcat/trunk/TOMCAT-NEXT.txt Mon Nov 3 13:16:36 2014 > @@ -15,210 +15,30 @@ > limitations under the License. > > ================================================================================ > > -Notes of things to consider for the next major Tomcat release (probably 8.0.x > -but possibly 7.1.x). > +Notes of things to consider for the next major Tomcat release (9.0.x) > > + 1. Fix Java 8 Javadoc warnings. Currently ~2800. > > + 2. Remove BIO AJP and HTTP connector.
I wonder about this goal. Something nice about the BIO connectors is that they tend to "just work" when other connectors are doing wonky things. Yes, they seriously complicate things like asynchronous semantics, but I think it may be more appropriate to simply drop support for async-over-blocking-IO and otherwise leave the BIO connector in there (not enabled by default). The BIO connectors seem to be the least resource-heavy for when work is actually being done (as opposed to having 1000 threads sitting idle, of course) which is a good use case for AJP which pretty much has a connection limit between httpd <-> Tomcat already. > + 3. Remove Comet support. Could we package Tomcat 8's Comet components in such a way that they could be added to Tomcat 9 by someone who might want to upgrade to Tomcat.latest but still use Comet? I actually think the protocol should die and from the (lack of) traffic on the list regarding Comet, I suspect its use is fairly limited. > + 5. SNI support for JSSE. This seems like a feature ripe for back-porting to Tomcat 8 when using a supportive JVM. > + 9. Refactor WebSocket I/O to go directly to Tomcat's internals rather than > via > + the Servlet API. I like this a lot. Is it actually in conflict with my above desire to continue to support the BIO connectors? > +10. Remove the use of system properties to control configuration wherever > + possible I like this, too. When anyone is working on moving a system property into configuration, please think about whether it would make sense (or be practical) for users to want to set these configuration settings on a per-web-application or per-host basis instead of only globally. Obviously, some configurations may only be applicable at the JVM level. For those, perhaps leaving them as system properties to stress their "globality" might be a good idea. -chris
signature.asc
Description: OpenPGP digital signature
