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 <ma...@apache.org> wrote: > On 02/02/2012 14:14, Costin Manolache wrote: > > On Thu, Feb 2, 2012 at 3:33 AM, Mark Thomas <ma...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
