tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: SPDY support
Date Tue, 14 Feb 2012 21:03:18 GMT
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 <markt@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message