BTW - one thing that may simplify the existing code is replacing SocketWrapper<E> with a simple SocketWrapper, and having JIO and APR define their own SocketWrapper - like NIO does.
It would also save a lot of Long->long->Long boxing. I'll try replacing Protocol/Processor with Handler, see how it looks. Costin On Tue, Feb 14, 2012 at 9:36 AM, Mark Thomas <ma...@apache.org> wrote: > 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 > >
