ApacheCon North America is almost concluding, and my experience this year has not disappointed. It’s been great to be able to meet up with lots of other project committers. Many committers make the trek to ApacheCon wherever it is in the world and, given that we normally work together just via the project mailing lists, it has been great to be able to discuss current issues and new ideas face to face. Of course, all of these discussions will be making their way (if they aren't there already) to the Tomcat dev mailing list so the everyone in the community can participate.
Personally, I have spent a great deal of my time in presentations. I have spoken about progress on Tomcat 8, delivered another session on clustering and two on security covering vulnerabilities and security response at the ASF. As always, slides are available from http://people.apache.org/~markt and there should be video and audio recordings available as well at some point. Most sessions were reasonably well attended and the conversation and questions flowed after the presentations. Here are some of the questions and answers I found most interesting:
Clarity of support. One of the key questions for users of Apache software is "What level of support is provided for security vulnerabilities?". It was great to hear Tomcat uses say that one of the things that they liked was the community's clear statements on what is supported and our policy of providing at least one year's notice before a major version is de-supported. Some of the questions from committers on other Apache projects were around "Which versions do we have to fix if we receive a security vulnerability report?". I think a few of them will be adopting something similar to Tomcat's approach to help clarify things for their users.
SPDY Protocol. Matthew Steele from Google gave a talk on implementing SPDY for HTTPD. For those that aren’t familiar, SPDY is a relatively (compared to HTTP) new protocol that essentially makes the web faster. However it does have one significant drawback in that it is limited to HTTPS connections. As an aside, a lot of the ideas from SPDY are being incorporated into HTTP 2.0 which, of course, won't have the HTTPS only limitation. This talk was particularly impressive as when the httpd community was first approached about SPDY they were pretty sure it would be impossible to implement. mod_spdy is a very nice piece of work. This naturally got me thinking about Tomcat's SPDY implementation. Tomcat does have an initial SPDY implementation but it is still very much in the development stage. Whether it progresses beyond this and becomes a formally supported protocol in Tomcat will depend, in part, on user feedback. If you'd like to see SPDY support in Tomcat let the Tomcat community know. Better yet, join the dev list and start helping with the development of SPDY. The code is currently in trunk where Tomcat 8 is being developed.
Which J2EE 7 Specifications are in Tomcat 8. How the Tomcat project goes about selecting J2EE specifications to implement is a classic question. Historically, Tomcat just stuck to implementing the three specifications of Servlet, JavaServer Pages and Expression Language, but with Tomcat 8 we will also be adopting WebSocket. Since we are adding another specification, there has been lots of questions to the community on whether there are any other specifications missing. Overall, it seems users are satisfied with the current selection of support for specifications Tomcat provides. This could be because if they want support for other specifications such as those in the Web Profile they can use TomEE, and if they want a full J2EE server they have Apache Geronimo, and so on. Regardless, it appears to be further validated that the Tomcat community is focused on the right specifications and support, and keeping Tomcat as a lightweight server with the options of combining other projects when additional support is needed is working for the community.
How Much a Security Vulnerability Drives a Release. Security was a theme to half of my sessions, plus I attended a few others. How much should a fix for a security vulnerability drive a release is a question that a number of Apache communities are grappling with at the moment. For the most part, how security vulnerabilities drive releases is decided on a case by case basis. In general, security fixes get prioritized if they are more severe or actively being exploited in the world. Besides that, it is balanced with the amount of resources we have to apply to a particular fix and the simple fact is, if it is a low level vulnerability it may well wait until the next scheduled release rather than driving a release.
As today gets started I am looking forward to stepping out of presentations for a bit and meeting directly with users on a more one on one basis. If you are around ApacheCon today, please do look for me or any of the other VMware team here supporting Apache Tomcat.