On 14/02/2012 08:29, Costin Manolache wrote: > Ok, took a bit to get the Apr polling to work and add some minimal tests. > > Please take another look - in particular to > https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java > > The spdy implementation seems to work with chrome, and the client seems to > work with google. > Probably still has plenty of bugs - but it's a start. > > If no objections - I'll start merging the LightProtocol/util.net changes > first, than add the spdy server implementation. The spdy client and tests - > probably later, I want to clean them up a bit more.
I am all for adding SPDY support to Tomcat asap including if practical to the 7.0.x branch (noting that there may be some API changes that may prevent this). I think the patch needs more discussion before it is committed to trunk. There are several areas where I am uncomfortable. My key areas of concern are: 1. The patch places Protocol like code (the code that works with the processors) in the endpoints. This significantly muddies the waters between Endpoint, Protocol and Processor which will make future maintenance more difficult. 2. Generic support for upgraded protocols is now available in trunk and SPDY should use this rather than adding SPDY specific upgrade handling. The generic upgrade process supports all three endpoints. Unless I am missing something the current SPDY implementation does not support NIO. 3. Having spent a considerable amount of effort cleaning up the connector code, removing duplicate code, resolving inconsistencies and making it easier to maintain, this patch feels like a step backwards. I am more than happy to see changes to the current generic HTTP upgrade support if it is not currently able to support SPDY. I also have some more cosmetic concerns but those are easily resolved. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
