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 08:29:11 GMT
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.

Costin


On Thu, Feb 2, 2012 at 6:37 AM, Mark Thomas <markt@apache.org> wrote:

> On 02/02/2012 14:14, Costin Manolache wrote:
> > On Thu, Feb 2, 2012 at 3:33 AM, Mark Thomas <markt@apache.org> wrote:
> >
> >> On 02/02/2012 10:05, Remy Maucherat wrote:
>
> >>> Ok, I think your "light protocol" concept to group any "upgraded"
> >>> connections is appropriate.
> >>
> >> Agreed. I'll see if I can wrap this into the generic upgrade process I
> >> added as part of the WebSocket support.
> >>
> >
> > My concern with the current upgrade process added for WebSocket is that
> > it's very heavy
> > in memory use.
>
> That is what I was agreeing with. I meant that I'll see if I can turn
> the current heavy-weight upgrade process into a light-weight one. As I
> have said before, this is already on my to-do list. I'll bump it up and
> start on it now so you have something to work with in trunk. I can steal
> ideas of you along the way :). That way we can hopefully get something
> pretty quickly into trunk that works for WebSocket and SPDY.
>
> > I think it would be better to go the other way - and use the
> >  LightProtoocl for WebSockets.
>
> Exactly.
>
> > If the app needs the original
> > Request/Response - we could
> > save them, but in most cases I don't think they'll be needed.
>
> I don;t see the need for that.
>
> 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