On 24/09/2015 14:52, Andrew Carr wrote: >> >> >>> I have been following the AJP enhancements for a long time and it seems >> the >>> protocol is stagnant. >> >> I prefer 'mature'. >> > > Apologies. Mature is a much more appropriate word. > > >>> I do see some updates in the last year to the >>> enhancements page and some of the bugs, but there is not much activity. >> I >>> search for "enhancements" under the Tomcat Connectors project in Bugzilla >>> because it does not seem as though there is a specific category for AJP >>> Protocol enhancements. I am very interested in starting work on the AJP >>> Protocol enhancements. It seems like the protocol needs a clear >>> specification. >> >> We have this: >> http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html >> >> I'd like to see that in more of an RFC style but the content (speaking >> as someone who spends a lot of time reading and then implementing specs) >> is pretty good. >> > > I have reviewed the page you mentioned, in detail. I was confused however, > because of the other page with ideas for the protocol enhancements. I see > where you cleared that up below. Maybe we need to state that the "ajpv13a" > page (or a new page) is the definitive resource for the new protocol > declaration. > > >> >>> Wouldn't a JSR for the protocol specification make sense? Aren't there >>> enough people on this list with a clear enough understanding to >> facilitate >>> introducing AJP 1.4 (or 2.0) as a JSR? >> >> -1. >> >> I don't believe that going via the JCP would add anything beneficial. >> > > I am in agreement with this and Rainer's comments. I was suggesting JCP as > a possibility, RFC style is perfectly O.K. as well. My goal is something > formalized. An RFC for AJP1.3a or AJP1.4 or 2, whatever, would accomplish > the same thing. > > >>> Even if we don't go the JCP route, shouldn't we work on the protocol? It >>> needs updating, imho. >> >> I do agree that there is benefit to updating the AJP protocol. Adding >> support for HTTP upgrade is the feature that pops to mind immediately. I >> also recall that we have used custom request attributes to pass >> additional attributes that didn't have a dedicated protocol attribute. >> >>> If you think I am wrong, please explain why, so that I may learn from the >>> experience. I have searched the lists and the interwebs for information >> on >>> this and I am having a hard time finding it. I have also been looking >> for >>> a place in the Tomcat project to dig in for 3 years, and I believe I have >>> finally found that place. >>> >>> Some other facts to support my argument about generating a specification, >>> it appears the enhancements to create the next AJP protocol are in >> multiple >>> locations. I know there is currently the AJP Extension Proposal, but >> what >>> about all of the AJP14 stuff floating around? >>> >>> https://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html >>> >> https://archive.apache.org/dist/tomcat/tomcat-connectors/jk2/v2.0.0/doc/common/AJPv14-proposal.html >> >> Those look to be largely the same ideas and date from roughly the same >> time (10+ years ago). >> > > Again, I agree, just think there should be a definitive definition of the > protocol. > > >> >>> Please let me know your thoughts and concerns on enhancing the AJP >> protocol >>> and possibly introducing a new version with new features. >> >> I think there is a clear case for a new version. The first thing to do >> would be to pull all the ideas together in one place (I'm thinking the >> wiki), agree what needs to be in AJP.next and then work on updating the >> specification to accommodate it. >> >> Regarding the wiki, the current Tomcat wiki is hosted on a system that >> be be very slow (minutes) to process updates. I think we should create a >> new wiki instance on the cwiki server that is a lot faster when editing. >> > > Should gathering ideas in the wiki wait until after it is moved to a new > instance, or will it all be migrated (so starting now on the new page would > be ok?)
Long term, we probably do need to migrate the wiki. Short term we can use the new instance just for this. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
